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Summary 

With  a  sufficiently  large  software  project,  the  time  between  the  development  of  the 
requirements  for  the  software  and  the  availability  of  an  operational  product  is  often 
measured  in  years.  The  longer  this  time,  the  less  likely  it  is  that  the  product  will  match 
die  desires  and  expectations  then  prevalent  among  the  user  community  The  of 
rapid  prototyping  is  to  shorten  the  time  between  the  development  of  requirements  and 
die  availability  of  a  prototype  operational  system.  , 

This  report  describes  the  results  of  work  on  Task  1,  a  part  of  the  first  year  of  work 
on  a  five-year  project  to  develop  a  programming  support  environment  and  a  collection 
of  tods  that  support  rapid  prototyping.  The  support  environment  is  based  on  the  PDSp 
a  system  developed  at  Harvard  University  {Cheatham  791  CPUS  82]  and  will  include  the 
tools  provided  by  die  PDS  plus  a  number  of  new  ones  specifically  supporting  rapid 
prototyping.  _ 

The  goals  of  Task  1  were  (1)  to  improve  two  tods  in  the  PDS  -  yr t  to 

improve  the  efficiency  of  one  and  generalize  the  other,  (2)  to  determine  what  ngf»«fo  to 
be  done  to  the  PDS  to  turn  it  into  a  production  system,  and  (3)  to  how  to 

convert  the  PDS  from  a  single-user  system  to  a  many-user  system.  We  summarize  our 
results  in  these  areas  in  the  following  paragraphs.  The  subsequent  sections  of  this 
document  contain  more  detail. 

We  unproved  three  tools  of  the  PDS.  In  one  case,  we  first  implemented  a  prototype 
to  test  the  design  of  the  tod  and  then,  when  satisfied  with  the  prototype,  we 
implemented  a  production  version  that  is  embedded  in  the  PDS.  In  case,  we 

needed  to  modify  a  utility  shared  by  several  tools.  We  began  with  a  single 
implementation  of  the  utility  and  realized  we  needed  diverse  implementations  for  the 
several  tods.  We  modified  the  abstract  model  for  the  utility  and  developed  the  several 
implementations  by  refinement  of  the  producing  a  program  family.  We 

these  various  enhancements  to  the  PDS  in  section  1. 

We  discuss  in  section  2  some  modifications  to  the  PDS  we  recommend  be  considered, 
and  in  section  3  we  discuss  the  issues  that  a  multiple-user  development  system  presents, 


to  move  forward  on  the  latter  project,  we  have  submitted  a  proposal  for  support  to 
continue  the  study  and  to  implement  a  prototype  of  one  component 


1.  Enhancement  of  existing  tools 

Task  1  calls  for  a  review  of  the  Harvard  Program  Development  System  (hereafter, 
called  the  PDS)  and  the  tools  it  provides.  In  light  of  the  results  of  this  review  and 
within  the  time  constraints  of  the  contract,  we  were  -to  design  and  implement 
modifications  to  die  tods  found  lacking  and  to  determine  whether  any  modifications  to 
the  basic  PDS  were  deemed  advisable.  The  tools  on  which  we  worked,  the  problems 
identified,  and  solutions  implemented  for  each  are  discussed  below. 

i 

LI  The  print  tool 

The  print  tool  takes  a  collection  of  modules  and  prepares  a  file  that  includes  a  table 
of  contents  and  formatted  ("pretty-printed")  program  test  for  the  attributes  of  the 
entities  in  the  modules.  The  problem  was  that  the  comment  attributes  were  printed  as 
strings  in  the  format  the  user  input  them.  Consequently,  users  usually  kept  the 
comments  short  and  kept  the  longer  descriptive  material  in  a  separate  text  file.  We  felt 
that  die  user  would  be  more  likely  to  keep  the  documentation  up  to  date  if  it  were  part 
of  the  code  module.  For  this  to  be  an  attractive  alternative,  we  would  have  to  have  a 
text  processor  format  the  comments.  A  solution,  the  one  being  implemented,  is  to 
provide  an  option  in  the  print  tool  to  produce  a  stream  of  text  for  a  text  formatter, 
with  the  program  text  "protected."  The  PDS  support  group  at  Harvard  is  modifying  the 
print  tool  in  this  way,  so  that  it  will  hand  die  comments  to  the  text  formatter,  Scr  i  be. 

L2  The  package  tool 

The  package  tool  takes  a  collection  of  concrete  modules  and  prepares  the  entities 
contained  therein  for  loading  (for  interpretive  execution)  or  compilation.  Its  major  task 
is  to  order  die  entities  so  that  each  is  defined  (bound)  before  it  is  used.  It  also 
identifies  sets  of  mutually  recursive  mode  definitions  and  groups  them  together  in  such  a 
way  that  they  get  defined  correctly.  The  original  package  tool  was  built  in  a  relatively 
ad  hoc  fashion  with  die  result  that  it  was  difficult  to  understand  and  modify.  We 
therefore  proposed  that  it  be  rewritten.  Tim  result  is  a  new  package  tool  that  is 
described  as  an  abstract  model  and  then  transformationally  refined  into  an  appropriate 
concrete  implementation,  hi  fact,  two  separate  refinements  were  done;  one  was  for  a 
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test  bed  environment  that  is  independent  of  the  PDS  and  the  second  is  the  production 
tool  integrated  into  the  PDS.  Appendix  A  contains  a  description  of  the  package  tool 
and  listings  of  the  set  of  modules  that  describe  the  abstract  model  and  die  refinements 
that  produce  the  two  concrete  implementations.  The  documentation  of  the  package  tool 
On  contrast  with  the  others)  is  a  collection  of  program  listings  attached  to  a  document 
that  describes  the  tool  and  references  various  entities  in  the  program  listing;  the  latter 
was  prepared  using  Scr  1  be. 

L3  The  analysis  tool 

The  analysis  tool  (named  FIJI,  shortened  from  "Find  Undefined  Identifiers")  provided 
by  the  PDS  scans  the  entities  in  a  module  and  produces 

1.  a  list  of  die  identifiers  occuring  within  an  entity  that  are  "undefined"  in  the 
sense  that  they  are  not  system  names,  not  names  of  entities  declared  to  be 
global,  and  not  local  variables,  and_ 

2.  a  list  of  the  global  user  procedures  called  by  the  entity.  This  list  is  optional 

Two  problems  were  identified  with  FUI.  The  first  was  that  it  could  (usefully) 
analyze  only  concrete  modules.  To  better  support  rapid  prototyping,  we  proposed 
extending  FUI  to  accept  partial  specifications  of  abstractions  and  to  analyze  the  abstract 
modules.  Then,  for  example,  one  could  certify  that  an  abstract  module  indudes 
definitions  (at  least  in  English)  of  the  constructs  it  uses  without  having  to  refine  the 
abstract  model  into  a  concrete  program.  For  FUI  to  be  able  to  analyze  an  abstract 
program  construct,  we  must  provide  some  means  for  the  user  to  "explain"  the  behavior 
of  the  construct  in  terms  that  FUI  can  understand.  For  example,  for  an  abstract 
iterator 

ForEachQueueElement  a  In  Q  Do  body  End 
we  would  like  to  state  that  its  behavior,  from  the  point  of  view  of  finding  undefined 
identifiers,  is  similar  to  the  concrete  construct 
FOR  a  FROM  Q  REPEAT  body  END 


We  call  such  an  explanation  an  analogy.  An  analogy  is  a  new  entity  attribute  in  the 
PDS;  it  has  a  form  very  much  like  a  rewrite.  For  the  above  case  we  would  provide  the 
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analogy 

ForEachQueueE lament  $S  e  In  t$  Q  Do  ??  body  End 
<~> 

FOR  SS  e  FROM  St  Q  REPEAT  ??  body  END 
]  The  left  (pattern)  part  of  the  analogy  (proceeding  ”<~>”)  tells  us  how  to  identify 
instances  of  the  abstract  construct;  the  right  (replacement)  part  tells  us  how  to  interpret 
the  match  variables  from  the  point  of  view  of  finding  undefined  identifiers.  For  the 
above  example,  we  would  infer  that  the  expression  matching  S5  Q  must  be  defined  at 
the  time  we  encounter  die  construct  and  that  the  expression  matching  $$  e  must  be  an 
identifier  and  that  it  is  a  local  variable  in  the  context  of  analyzing  die  list  of  statements 
matching  ??  body. 

The  second  problem  identified  with  FUI  was  that  h  did  not  provide  any  context  to 
help  the  user  find  the  unknown  identifier.  We  solved  this  problem  by  returning,  in 
addition  to  the  unknown  identifier,  a  template  that,  by  indicating  blocks  and  loops 
entered  and  giving  statement  counts  of  the  statements  preceding  that  containing  the 
unknown  identifier,  provides  sufficient  context  to  locate  the  construct  containing  die 
identifier.  Because  of  insufficient  time,  this  part  of  die  model  is  not  as  readable,  not  as 
good  an  abstract  model,  as  the  other  parts  of  the  FUI  implementation. 

Appendix  C  contains  the  abstract  model  of  FUI.  In  this  instance  the  commentary 
and  program  entities  are  in  a  single  module. 

14  The  analyze  utility 

There  are  a  number  of  tods  that  analyze  a  program  construct  to  locate,  and  assess 
the  meaning  of,  identifiers  occuring  in  that  construct 

1.  The  package  tool  looks  for  the  interdependencies  among  a  collection  of 
program  entities. 

2.  The  synonym  tod  systematically  replaces  all  occurrences  of  some  identifier 
(that  refers  to  a  globally  defined  entity)  by  a  new  name. 

3.  FUI  finds  and  records  occurrences  of  undefined  identifiers. 


Prior  to  extending  FUI  to  use  analogies  to  explain  abstract  constructs,  a  single  PDS 
utility,  called  Analyze,  did  ail  these  tasks.  Analyze  recursively  evaluated  a  program 
entity,  maintaining  as  a  "current  context"  the  set  of  identifiers  that  name  local  variables. 
When  it  encountered  a  variable  name  not  local  and  not  a  global  system  name,  it  called 
upon  a  procedure  supplied  by  its  client  -  that  is,  FUI,  the  package  tool,  or  die  synonym 
tool  -  that  kept  whatever  records  the  client  needed.  With  the  changes  to  FUI,  however, 
die  old  Ana  I  yze  was  no  longer  able  to  do  the  job.  It  would  have  had  to  be  extended 
to  deal  with  analogies  and  to  maintain  sufficient  contextual  information  to  build  a 
template.  Except  for  this  additional  functionality,  the  bulk  of  die  recursive  evaluator  of 
the  Analyze  would  remain  unchanged.  In  order  to  produce  the  two  similar  but  distinct 
instances  of  Analyze  for  the  two  different  kinds  of  client  tools,  we  proceeded  as 
follows.  First  we  developed  an  abstract  model  of  the  recursive  evaluator,  deferring  the 
issues  of  what  records  should  be  kept  and  how  to  keep  them.  We  then  developed  two 
refinements  of  the  abstract  model,  one  .producing  an  analyzer  for  FUI  and  die  other 
producing  an  analyzer  for  die  other  two  client  tods.  Appendix  B  describes  this  two 
member -family. 


2.  Recommended  modifications  to  the  PDS 

The  overall  organization  of  the  PDS  and  the  tool  set  presently  available  provide  good 
support  for  the  transformational  refinement  paradigm  for  developing  and  maintaining 
programs  and  program  families.  There  are,  however,  a  number  of  areas  where 
modifications  to  the  PDS  would  significantly  enhance  it,  particularly  for  use  in  projects 
that  involve  a  number  of  people  working  together. 

In  the  paragraphs  below  we  comment  on  three  broad  areas  in  which  modifications  are 
recommended. 

2JL  Specifying  relationships  among  modules 

In  the  present  PDS,  the  relationships  among  modules  are  specified  by 

1.  the  uses  attribute,  which  indicates  that  one  module  uses  the  entities  exported 

by  another,  and  _ 

2.  the  history  attribute,  constructed  for  a  module  produced  by  the  merge  tod 
or  the  transform  tooL 

Neither  of  these  provides  enough  information.  For  example,  the  user  might  want  to 
inform  an  analyzer  that  two  modules  are  later  to  be  combined. 

We  recommend  that  these  mechanisms  be  replaced  by  a  single  specification  attribute. 
Specifications  would  include 

1.  the  came  (partition,  and  so  on)  of  the  module, 

2.  the  tod  to  be  used  to  produce  the  module,  and 

3.  the  sets  of  other  modules  to  which  this  module  is  related. 

The  sets,  in  the  last  instance,  would  depend  upon  the  tool  used  to  derive  the  module. 
For  example,  if  the  edit  tod  is  used,  the  set  of  associated  modules  of  interest  is  that  of 
the  modules  that  supply  imported  syntax.  If  the  analysis  tool  is  used,  there  would  be 
several  sets:  the  set  of  modules  to  be  co*analyzed,  the  set  supplying  imported  syntax,  and 
the  set  containing  entities  assumed  to  be  bound  globally. 


12  User  interface 

The  user  interface  to  the  PDS  is  a  simple  command  language  designed  when  the  only 
terminals  available  were  the  relatively  slow  line-at-a-time  devices.  With  the  availability 
of  high  resolution  graphics  terminals  capable  of  supporting  multiple  windows  and 
multiple  fonts  and  providing  various  kinds  of  pointing  devices,  a  much  more  imaginative 
user  interface  is  in  order. 
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3.  A  lifecycle  support  system 

The  development  and  subsequent  maintenance  and/or  enhancement  of  large 
application  programs  and  program  families  often  involves  a  number  of  agents  -  analysts, 
programmers,  test  engineers,  managers,  documentation  specialists,  and  end  users.  The 
activities  of  the  agents  require  various  kinds  of  coordination.  For  **ample,  suppose  that 
an  agent  has  the  task  of  modifying  a  program  module.  Before  incorporating  the  results 
of  his  modifications  into  a  new  release,  we  would  like  to  ensure  that  certain  tests  have 
been  performed  satisfactorily,  that  the  changes  are  logged  appropriately,  that  any 
relevant  documentation  is  updated,  and,  finally,  that  the  agent  obtains  the  approval  of 
an  appropriate  manager  before  releasing  the  result. 


The  PDS  supports  a  subset  of  these  lifecycle  activities,  those  of  the  programmers  and 
analysis  developing  and  modifying  software.  The  only  coordination  the  PDS  provides  is 
through  its  version  control  and  derivation  history  mechanisms.  That  is,  one  can 
determine  the  elements  of  the  PDS  software  database  that  are  up  to  date  and  those  that 
are  not  because  each  module  bears  a  version  number;  additionally,  because  each  module 
contains  a  derivation  history  that  indicates  what  tool  was  employed  to  derive  it  and 


what  other  (parent)  modules  were  involved  in  its  derivation,  it  is  possible  to  update 
automatically  a  collection  of  modules  following  changes  to  one  or  more  of  them.  The 
PDS  provides  relatively  little  support  for  the  coordination  suggested  above;  it  is  left  to 
the  agents  communicating  informally  and  to  managers  overseeing  the  process  to  ensure 
that  a  release  protocol  such  as  that  sketched  above  is  followed. 

The  baric  framework  of  the  PDS  (the  software  database,  the  explicit  representation 
of  the  relationships  amongst  its  elements,  and  the  integrated  toolset  for  exploring  and 
augmenting  the  software  database)  can  be  extended  to  provide  facilities  and  services  for 
a  wider  range  of  the  software  lifecycle  activities.  In  addition  an  extended  PDS  could 
provide  the  mechanisms  for  coordinating  the  activities  involved  in  carrying  out  tasks 
such  as  the  one  sketched  above.  In  the  following  paragraphs  we  sketch  the  overall 
organization  of  such  a  system;  to  name  this  sytem,  we  tentatively  put  forward  the 
acronym  LISUS  -  to  suggest  a  Lifecycle  Support  System.  (We  have  used  the  name 
MUPDS  in  previous  documents,  standing  for  Multiple  User  PDS.) 
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3J.  Elements  of  LISUS 

The  PDS  handles  modules,  sets  of  modules,  and  tools.  LISUS  will  interact  with  these 
classes  of  objects,  as  described  below,  plus  some  new  ones. 

3.1.1  Modules  and  sets  of  modules 

As  with  the  PDS,  LISUS  will  deal  with  a  collection  of  modules  -  the  containers  for 
the  information  that  constitutes  the  software  database.  The  software  database  will  be 
organized  into  hierarchically  related  collections  of  modules.  As  with  the  PDS,  the 
creation,  modification,  and  deletion  of  files  used  to  represent  modules  will  be  entirely 
under  control  of  LISUS. 

3.1.2  Agents  and  organizations 

By  an  agent  we  mean  a  person  in  an  organizational  hierarchy  who  has  a  role  in  the 
current  set  of  activities  being  carried  out-with  LISUS.  A  human  being  will  play  the  role 
of  an  agent  by  "logging  in"  as  that  agent  and  issuing  commands  to  LISUS.  An 
organization  is  a  collection  of  agents  and  (sub-)  organizations.  The  set  of  agents  and 
organizations  at  a  given  point  in  time  provides  an  organization  chart  for  the  projects 
guided  by  LISUS. 

3.1.3  Messages 

Messages  provide  the  means  for  communication  among  agents  and  organizations.  A 
message  will  typically  have  a  relatively  short  lifetime  -  it  will  be  created  by  an  agent 
(possibly  on  behalf  of  an  organization)  and  dispatched  to  an  agent  or  organization.  It 
will  eventually  be  accepted  by  some  agent  who  may  then  take  certain  actions  on  the 
bans  of  the  message.  There  will  be  several  types  of  messages,  including  those  described 
below. 

1.  A  comment  is  a  message  that  offers  information  with  no  expectation  of  a 
response. 

2.  A  query  is  a  message  sent  to  elicit  a  response.  A  query  would  be  sent  to 
determine,  for  example,  the  status  of  a  module  or  a  problem  (bug)  report 
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3.  A  reply  refers  to  a  query  and  provides  the  answer. 
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4.  A  request  for  permission  is  sent  by  an  agent  to  another  agent  or  organization 
when  he  wishes  to  take  a  step  that  requires  authorization.  The  agent  who 
receives  the  request  (perhaps  on  behalf  of  the  recipient  organization) 
responds  with  a  message  that  constitutes  a  grant  or  denial  of  the  request 

5.  A  grant  of  permission  refen  to  a  request  for  permission  and  conveys  the 
permission  requested.  The  agent  supplying  a  grant  must,  of  course,  have  the 
authority  to  do  so.  A  grant  of  permission  may  include  constraints,  for 
example,  to  ensure  that  the  requesting  agent  follows  a  certain  procedure. 

6.  A  denial  of  permission  refen  to  a  request  for  permission  and  constitutes  a 
refusal  to  grant  the  permission  requested. 

Messages  in  LISUS  will  have  a  type  (per  the  above  list)  and  references  to  other 
elements  of  the  system,  such  as  the  sending  agent,  a  previous  message,  one  or  more 
modules,  or  a  protocol.  (Protocols  are  described  in  section  2.3.2  below).  An  audit  trail 
will  be  kept  feu  each  currently  active  message. 

3.1.4  Tools 

The  tools  available  in  LISUS  will  include  those  in  PDS.  Additionally,  there  will  be 
tools  for  creating,  distributing,  and  tracing  messages  and  for  developing  and  testing 
protocols. 

322  Activities  and  protocols 

At  any  time  there  will  be  a  set  of  activities  that  LISUS  knows  about  The  goal  of 
each  ongoing  activity  is  for  some  agent  to  accomplish  some  task.  Examples  of  such 
tasks  range  from  answering  a  query  to  generating  a  new  application  program  release. 

Each  ongoing  activity  will  have  associated  with  it  the  agent  or  organization  that  is 
engaged  in  carrying  out  that  activity.  Also  associated  with  an  activity  is  a  set  of  states, 
at  any  point  a  given  activity  is  in  exactly  one  state.  Associated  with  each  state  is  a  set 
of  choices  of  actions  that  are  available  to  the  agent  Certain  choices  may  result  in  a 
transition  to  a  new  state,  while  others  would  result  in  the  activity  remaining  in  the  same 
state.  For  example,  a  choice  to  dispatch  a  request  for  permission  may  result  in  a 
transition  to  a  "wait"  state  awaiting  the  grant  or  denial  of  the  request  The  arrival  of, 
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for  example,  a  grant  of  the  request  will  then  result  in  the  transition  to  a  state  in  which 
the  agent  will  have  available  a  number  of  new  choices  that  are  by  the  grant  of 

permission. 

A  choice  may  be  constrained  by  a  predicate  that  must  be  true  in  order  for  the  choice 
to  be  valid.  The  truth  (or  falsity)  of  a  predicate  is  established  in  accordance  with  a  set 
of  rules  that  describe  how  to  evaluate  predicates. 

An  activity  may  be  divided  into  a  set  of  subactivities  that  can  be  carried  out  in 
parallel.  For  example,  the  task  of  modifying  a  program  module  may  involve  doing  the 
modification  and  then  submitting  the  modified  module  to  a  set  of  tests.  It  might  also 
involve  logging  the  changes  made  and  modifying  the  documentation  to  reflect  the 
changes.  It  thus  might  be  convenient  to  consider  the  program  modification/test,  the 
logging  of  changes,  and  the  document  modification  to  be  three  (sub)  activities  that  can 
be  carried  out  in  parallel.  ~ 

The  set  of  states,  the  choices  for  each  state,  the  transitions,  and  the  predicates 
constraining  a  transition  are  collectively  termed  a  protocol.  A  protocol  may  be  general 
in  the  sense  that  it  has  parameters  that  may  be  bound  to  particular  objects  (agents, 
organizations,  modules,  messages,  or  other  activities)  for  each  instance  of  use. 

The  current  state  of  an  activity  and  the  trace  of  the  control  path  through  the 
protocol  underlying  that  activity  to  the  current  state  provide  the  basis  for  answering 
questions  regarding  the  status  of  that  activity  and  its  history.  Projecting  possible  future 
states  may  also  provide  a  basis  for  developing  a  program  for  the  future  of  the  activity. 

&3  Rules 

There  are  two  kinds  of  rules  proposed  for  LISUS.  One  kind,  the  specific  rules  are 
(ground)  predicates  that  describe  the  fixed  relationships  among  the  various  elements  of 
the  system.  Examples  of  specific  rules  include  the  following: 

Agent  Son  works  for  organization  Able. 

Organization  Able  owns  directory  S. 

Module  Foo  is  in  directory  S. 

Here  "works  for,"  "owns,"  and  "is  in"  are  (two  place)  predicates,  and  Sam,  Able,  S,  and 
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Foo  are  names  of  specific  elements  (an  agent,  an  organization,  a  directory,  and  a 
module,  respectively).  It  could  be  advantageous  to  think  of  the  specific  rules  as  deriving 
from  a  set  of  relations  contained  in  a  relational  database.  The  query  and  update 
facilities  could  be  used  to  inspect  and  modify  the  specific  rules. 

The  second  kind  of  rule,  the  general  rule,  is  a  rule  that  includes  variables  and  thus 
may  be  true  for  a  set  of  elements  in  the  system.  The  following  is  an  example  of  a 
general  rule: 

ForaD(<zagent,  ^organization,  rf:  directory,  rr:  module) 

Assert  a  can  modify  m 

If  a  works  for  g  and 

g  owns  d  and 
m  is  in  d. 

Here  a,  g,  d,  and  m  are  variables  that  range  over  the  set  of  agents,  organizations, 
directories,  and  modules,  respectively.  Given  this  general  rule  plus  the  specific  rules 
cited  earlier,  the  predicate 
Sam  can  modify  Foo 

is  demonstrated  to  be  true  by  binding  the  variables  occurring  in  the  general  rule  as 

follows: 

a.  Sam 
g.  Able 
±  S 
m:  Foo 

A  general  rule  can  also  provide  a  strategy  for  progressing  through  an  activity.  An 
example  is 

Forall  (oagent,  /n  module) 

Assert  a  can  modify  m 

If  a  works  for  Able  and 

m  is  in  S  and 

CanObtainPermissionToModify(4m>/okn) 

Suppose  that,  using  this  rule,  we  wish  to  establish  that  Sam  can  modify  Foo.  The 
predicates  a  works  for  Able  and  Foo  is  in  5  are  established  as  true  by  appealing  to  two 
of  the  specific  rules  cited  earlier.  Satisfaction  of  the  predicate 
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CaaObtainPcrmissionT oModify /n,7oAn)  would  result  from  the  success  of  a  request  to 
the  agent  named  John  for  permission  for  Sam  to  modify  Foo. 

Yet  another  use  of  a  general  rule  is  to  coordinate  the  modification  of  a  module. 
Such  a  rule  would  include  premises  that  established  pre-conditions  and  a  final  premise 
that  established  a  protocol  for  the  user  to  follow  in  doing  the  modification,  effectively 
specifying  a  set  of  subactivities  that  the  user  is  constrained  to  carry  out 

To  summarize,  we  propose  to  control  and  coordinate  activities  through 
•  lock  and  key  mechanisms  described  by  a  set  of  specific  rules, 

-  formal  procedures  aa  described  by  a  set  of  general  rules,  and 

-  formal  permission  messages,  to  monitor  and  control  activities  for  which  the 
control  procedures  could  not  be  (or  have  not  been)  sufficiently  formalized  to 
be  represented  as  a  set  of  general  rales. 

The  general  and  specific  rules  that  can  be  stated  (and  thus  the  relationships  among 
elements  that  can  be  established)  are  powerful  (technically,  any  formula  in  a  mildly 
restricted  and  typed  first  order  predicate  calculus).  We  note  that  the  basis  for  the  rales 
discussed  above  is  die  PROLOG  language.  (PROLOG  systems  have  been  popular  in 
Europe  for  several  years  and  are  gaining  in  popularity  in  the  U.S.  The  Japanese  have 
taken  PROLOG  as  the  basis  for  their  fifth  generation  computer  project)  There  are 
well  understood  techniques  for  implementing  PROLOG  interpreters  (programs  that, 
given  some  base  set  of  specific  and  general  rules,  determine  whether  a  predicate  is  true 
or  false  with  respect  to  the  base  set)  and  compilers. 


4.  Conclusions 

The  three  general  areas  of  that  are  proposed  are  quite  different  in  their  effect 

on  the  n^falnwia  of  the  PDS  in  large  programming  projects.  The  ability  to  specify 
relationships  among  modules  would  be  an  asset  and  an  improved  user  interface  would  be 
an  asset,  each  would  >nl'anf*  a  user’s  productivity.  By  contrast,  the  LISUS  proposal 
would  result  in  a  system  appropriate  for  large  scale  projects  involving  many  people 
working  simultaneously.  With  it,  the  high  payoff  of  using  a  system  like  die  PDS  in 
fnaii  and  medium  scale  projects  could  be  realized  is  large  scale  projects. 
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Appendix  A 

Implementation  of  the  PDS  Package  Tool 


L  Overview 

Given  a  set  of  “events”  the  purpose  of  Package  is  to  order  or  schedule  these  events  so  that 
if  event  F  depends  upon  E  having  already  occnred  then  event  E  will  precede  event  F  in  the 
ordering.  That  is.  Package  does  a  topological  sort  of  a  set  of  events  with  respect  to  a 
“depends  upon”  relation.  There  are  three  sorts  of  events  that  we  consider  Type, 
Binding,  and  Initialization.  These  correspond  to  the  typing  (Le.,  the  mode  definition)  the 
binding,  and  the  initialization  of  top-level  ELI  program  quantities.  As  an  example,  consider 
the  set: 

Type(0.  M)  Binding(Q,  CONST(M  SIZE  N)) 

Type<M.  MODE)  Binding(M,  SEQ(INT)) 

TypefN,  INT)  Bmding(N,  CONST(INT))  Initialization(N<-f(6)) 

Type(f,  PROC(INT;  INT))  Binding(f_£XPR(xJNT;  INT)0  i  LT  1  »>  1;  r  0 

In  general,  the  Type  event  for  some  quantity,  x,  must  precede  the  Binding  event  for  x  and 
that,  in  turn,  must  precede  the  Initialization  event  for  x.  Further  if  event  E  depends  upon 
the  quantity  x,  then  the  Type,  Binding,  and  Initialization  events  for  x  must  precede  E.  Thus, 
in  addition  to  Type  before  Binding  before  Initialization,  the  above  example  set  is  constrained 
so  that  Binding(M)  precedes  Type(0),  Initialization(N)  precedes  Binding(O),  Binding(f) 
precedes  Initialization(N),  and  so  on.  One  acceptable  ordering  of  these  events  is 

Type(M),  Type(N),  Type(f)»  Binding (M).  Type(0),  Binding(f).  Binding(N), 
Initialization(N).  Binding(O). 

There  are,  of  course,  a  number  of  other  orderings  that  are  acceptable.  There  are  two  uses 
of  an  ordering  of  events  that  is  produced  by  Package.  The  first  is  to  control  the  loading  of 
a  collection  of  (top-level)  bindings  and  associated  initializations  into  an  ECL  environment 
(Far  this  application  the  Type  events  can  be  effectively  ignored.)  The  second  use  is  by  the 
compiler.  If  we  are  compiling  the  program  entities  in  some  module,  C,  and  that  module  uses 
module  M  (in  the  sense  that  Uses(— .M,"')  is  an  attribute  of  module  C)  then  the  compiler 
must  evaluate  the  type  (mode)  of  all  the  entities  in  M  so  that  references  to  them  by  the 
entities  of  C  being  compiled  can  be  type  checked.  Thus  for  the  above  example,  the  first  five 
events  are  of  interest  to  the  compiler  for  this  purpose  and  the  remaining  four  are  not  A 
special  event,  called  the  "ReadyToCompile”  event  is  inserted  into  the  output  sequence  to 
signal  the  end  of  events  of  interest  to  the  compiler.  Package  has  one  further  job,  namely  to 
deal  with  sets  of  mutually  recursive  mode  hfaHing?  by  coalescing  such  sets  into  a  single 
“twiddle”  event  For  example,  the  classic  pair 
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Lift  <•  PTR.(ListElement) 

ListElement  <•  STRUCT(EJNT,  Nextiist) 

is  to  be  coalesced  into  the  single  twiddle  binding: 

<  List,  ListElement  >  <~ 

<  PTR(<~  ListElement),  STEUCT(EJNT.  Next<~  List)  >. 

The  basic  method  of  scheduling  some  event,  E,  is  to  scan  the  value  of  the  event  and  insure 
that  for  each  quantity,  x,  referenced  in  that  value,  die  Type,  Binding,  and  Initialization 
events  for  x  are  scheduled  before  E  (recursively).  We  therefore  introduce  a  stack  of  events 
that  are  currently  being  scheduled.  If  in  scheduling  some  event.  E,  we  note  that  it  requires 
an  event,  F,  that  is  already  stacked,  we  note  die  mutual  dependence.  This  may  lead  to  a 
"twiddle”  event  or  it  may  signal  an  unresol vable  circularity  as  for  example  with  the  pair: 

Btoding(N,  CONST(INT  LIKE  K)) 

Binding(K,  CONSTANT  LIKE  N)). 

If  events  E  and  F  are  stacked  with  E  below  F  then  E  clearly  depends  upon  F  (perhaps  not 
direcdy).  We  record  the  dependence  in  the  other  direction  by  providing  a  field  in  the  stack 
entry  for  an  event,  say  event  E,  in  which  we  record  the  lowest  index  in  the  stack  that  is  for 
an  event  that  is  prior  to  E  in  die  stack  and  upon  which  E  depends.  The  inning  0f  the 
value  of  an  event  is  carried  out  by  a  general  purpose  analysis  tool.  Given  some  FORM,  f ,  to 
be  scanned  this  tool  basically  does  a  weak  interpretation  of  f,  constructing  a  local  names 
environment  For  each  identifier,  x,  that  is  not  local  to  the  current  point  of  evaluation  and 
is  not  an  ELI  system  name,  it  calls  a  special  procedure  (supplied  by  the  call  on  the  Analyzer 
tool)  which,  in  the  Package  application,  will,  in  turn,  call  for  the  scheduling  of  the  Type. 
Binding,  and  Initialization  events  for  x.  The  remainder  of  this  document  is  organized  as 
follows.  Section  2  describes  the  abstract  model  for  Package.  Section  3  then  discusses  two 
basic  strategies  for  implementing  Package.  One  is  concerned  with  obtaining  a  prototype  in 
which  we  can  study  the  scheduling  algorithm;  we  will  not  be  particularly  concerned  with 
efficiency  in  this  implementation.  The  second  implementation  is  as  a  fully  integrated  PDS 
tool.  This  implementation  is  concerned  with  efficiency.  Section  4  then  discusses  various 
details  of  the  implementation  of  the  prototype  Package  and  section  5  is  concerned  with  the 
implementation  of  Package  as  a  PDS  tool  A  listing  of  all  the  modules  involved  is  included 
in  appendix  A. 


2.  The  Abstract  Model  for  Package 

The  abstract  model  for  Package  is  provided  by  the  module  named  Package.  This  module 
contains  several  scopes  which  we  discuss  below. 


2.1.  Scope(MasterCoatrol) 

la  addition  to  providing  notations  for  iterators  and  for  adding  elements  to  and  testing  for 
membership  in  sets,  this  scope  has  two  entities:  Package,  the  top-level  event  scheduling 
routine,  and  SchedulingSnccessfnl,  a  BOOL  that  will  be  set  TRUE  initially  and  subsequently 
set  to  FALSE  if  any  difficulties  (e.g.  an  unaccountable  circularity  among  events)  are 
encountered. 


Package[l-2] 


Now  bracketed  pairs  of  numbers,  a  **[1-2]“,  key  to 
the  entity  number  in  the  corraaponding  listing. 

Package  takes  two  arguments: 


Bases:  Set(Module)  —  the  set  of  modules  whose  entities  provide  the  set  of  events  to  be 
scheduled. 


PackagesReferenced:  Set  (Module)  —  the  set  of  modules  whose  (exported)  entities  are 
to  be  assumed  as  globals  in  the  environment  when  the  events  of  Bases  are  loaded 
or  are  compiled. 

Package  returns  a  Quene(Event);  if  ScfaedulingSuccessful  is  TRUE  this  Queue(Event) 
provides  one  acceptable  ordering  of  /ie  events  in  Bases  (plus  the  Ready ToCompile  event 
marking  the  end  of  events  of  interest  to  the  compiler  when  it  is  compiling  some  other 
module  that  uses  this  package).  The  several  stages  of  Package  are  as  follows: 

(a)  We  introduce 


EveoteSetOEvent)  —  the  set  of  events  (initially  empty)  to  be  scheduled. 

Global*:  Set(EntityName)  —  the  set  of  names  (initially  empty)  of  entities  assumed  to 
be  in  the  environment 


(b)  For  each  module  B  in  Bases,  each  entity  E  in  B,  and  each  event  template  T  for  E  we 
determine  whether  there  is  already  an  event  v  for  T,  and  if  not  add  a  new  event  to  Events 
corresponding  to  T.  Here  an  event  template  provides  s  bridge  between  the  representation  of 
an  event  within  an  entity  of  a  module  and  the  representation  of  that  event  particular  to 
Package.  It  will  be  refined  in  different  ways  for  the  two  implementations. 

(c)  For  each  module  P  in  PackagesReferenced  and  each  entity  E  in  P,  we  add  the  name  of  E 
to  die  set  Global*. 


(d)  We  introduce: 
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ScheduledE vents KJueue<E vent)  —  a  queue  of  events  (initially  empty)  to  which  will  be 
added  the  elements  of  Events  as  they  are  scheduled. 

StackedE  ventstS  tack  (Even  tEntity)  —  a  stack  in  which  we  will  record  the  collection  of 
events  currenty  being  scheduled  and  their  interdependence. 

TopdNT  —  the  index  in  StackedE  vents  of  the  current  top-most  dement 

These  three  quantities  will  be  manipulated  by  ScheduleE  vcnt[2-2]  and  SchedulePer5tack[2-3] 
(to  which  they  are  passed  SHARED  as  arguments). 

(e)  We  now  «ehi»d"i«  the  Type  events  and  the  Binding  events  that  correspond  to  mode 
bindings. 

(f)  The  Ready ToCompiie  event  is  then  added  to  the  queue  of  scheduled  events  to  mark  the 
last  event  of  interest  to  the  compiler. 

(g)  The  remaining  (unscheduled)  Binding  events  and  the  Initialization  events  are  then 
scheduled  and  ScheduleE  vents  returned  as  the  result  of  Package. 

Ul.  Scope( Scheduling) 

In  aHititirm  to  introducing  some  notation  for  iteration  and  for  adding  events  to  the  queue, 
the  Scheduling  scope  presents  the  several  routines  that  have  to  do  with  scheduling  an  event. 

SchednlcEvent(2-2] 

ScheduleE  vent  takw»  as  argument  E,  the  Event  to  be  scheduled,  and  shares  the  quantities 
ScheduledEvents,  StackedE  vents,  and  Top  introduced  in  Package.  The  several  stages  of 
ScheduleEvent  are  as  follows: 

(a)  If  E  is  a  null  event  or  is  already  scheduled  we  exit  immediately. 

(b)  Otherwise  we  determine  if  E  is  already  stacked  and.  if  so.  record  that  the  event  that  is 

currently  being  (Le.,  the  one  that  is  topmost  on  the  stack)  depends  upon  E  by 

setting  its  LowestReference  Held  to  the  index  of  the  stack  entry  for  E  (unless  it  already 
references  an  event  preceeding  E).  If  E  is  stacked,  we  then  exit 

(c)  Otherwise,  we  insure  that  the  type  event  precedes  the  binding  event  and  that  it  precedes 
the  initialization  event  for  the  quantity  associated  with  E.  We  also  introduce  the  local 
variables  CurrentScanEventAttribute  and  CurrentScanEventName.  These  variables  are  used 
by  UnknownAtomError  [3-5]  when  it  announces  undefined  identifiers. 

(d)  If  E  is  an  event  binding  an  explicit  procedure  (EXPR)  we  schedule  E  immediately  since 
any  modes  upon  which  it  depends  have  already  been  scheduled  (because  its  type  event 
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proceeded  its  binding  event)  and  nothing  else  is  required  in  order  to  load  or  to  compile  an 
EXPR. 

(e)  We  increment  the  current  topmost  stack  index  (Le.  Top);  the  construct  Increment  (Top) 
is  employed  to  force  any  storage  management  activities  required  to  insure  a  sufficiently  large 
stack.  We  then  install  event  E  as  the  new  top  element  in  StackedEvents  and  initialize  its 
LowestReference  field  to  be  Top  +  1;  if  the  event  is  self  dependent  (as  in  “L  <- 
PTR(STRUCT (EJNT,  NexfcL))"  )  this  field  will  eventually  be  set  to  Top  and  if  the  event 
depends  upon  events  proceeding  it  in  the  stack  it  will  be  set  to  the  index  within  the  stack  of 
the  earliest  of  these.  If  it  depends  only  on  events  that  are  scheduled  ahead  of  it,  the 
LowestReference  field  will  remain  set  to  Top  +  1. 

(f)  We  rtwn  call  ScanEvent(E)  to  scan  the  value  of  event  E  and  schedule  any  events  that  E 
depends  upon  ahead  of  E  (or  note  mutual  interdependencies). 

(g)  If  Top  is  now  zero  the  stack  is  empty  and  we  are  though.  Top  can  be  zero  because  the 
events  that  are  stacked  may  be  scheduled  in  'clumps’*  of  mutually  dependent  events.  (See 
discussion  of  SchedulePerStack[2-3D.  _ 

(h)  Otherwise,  we  will  locate  the  current  set  of  events  to  be  scheduled.  We  initialize  the 
variable  First  to  Top  and  then  proceed  down  the  stack  to  find  the  lowest  index  referenced 
by  Top  or  by  any  entry  between  Top  and  its  lowest  reference,  recursively.  Following  the 
loop.  First  will  index  the  earliest  and  Top  the  latest  in  a  set  of  mutually  interdependent 
stack  entries.  We  then  call  SchedulePerStack  to  do  the  checking  and  actual  scheduling.  We 
note  that  one  side  effect  of  the  call  on  SchedulePerStack  is  that  Top  will  be  set  to  First  -  1 
to  reflect  the  fact  that  the  First  through  Top  elements  have  been  taken  care  of.* 

We  observe  that  ScheduleEvent  is  called  recursively  as  new  dependencies  are  detected  (see 
Scope(Scanning)  for  details)  by  ScanEvent  The  actual  scheduling  of  events  (by 
SchedulePerStack)  is  done  in  “clumps”  of  mutually  interdependent  entries. 

Scfce*al«PerStack[3-2] 

SchedulePerStack  takes  four  arguments;  it  shares  ScheduledE vents.  StackedEvents,  and 
Top  (introduced  in  Package  and  passed  shared  through  ScheduleEvent  who  is  the  only  caller 
of  SchedulePerStack)  and  takes  First,  the  index  in  StackedEvents  of  the  first  event  (Top 
being  the  last)  in  a  set  of  mutually  interdependent  events  to  be  scheduled. 

SchedulePerStack  splits  into  two  cases:  First  =  Top  and  First  <  Top.  (First  >  Top  being 
impossible)  as  follows: 


*For  technical  reason  (wa  SehadulaParStaek[2-3])  this  is  oot  dona  by  SchadulaEvant  directly. 


(a)  First  *  Top:  Here  we  have  a  single  (possibly  self  dependent)  event,  E.  If  E  has  already 
been  schednled  (for  example  because  it  is  an  EXPR  binding)  then  we  have  nothing  further 
to  do  and  so  reset  Top  and  terminate  SchedulePerStack.  If  it  is  a  self  dependent  mode 
binding  (as  for  example  with  L  <-  PTR(STR.UCT(...,  NexfcL)) )  we  replace  E  by  an 
appropriate  twiddle  event  (in  the  above  example  by  <L><~  PTR(STRUCT Next.<~ 
L»  ).  We  then  add  E  to  the  queue  ScheduledEvents.  Finally,  if  E  is  a  mode  binding  event, 
we  call  ScheduleQuotedBehaviorFunctions(E)  to  schedule  the  Type,  Binding,  and 
Initialization  of  the  quoted  behavior  functions  (those  naming  functions  that  implement  the 
various  user  defined  behavior  elements)  associated  with  E. 

(b)  First  <  Top:  Here  entries  First  through  Top  in  StackedE vents  are  a  set  of  mutually 
interdependent  events.  Included  among  them  may  be  certain  events  that  have  already  been 
scheduled  and  we  simply  ignore  these.  If  each  non-schcdulcd  event  is  a  mode  binding  event 
we  coalesce  them  into  a  single  twiddle  event,  E,  add  it  to  the  queue,  and  schedule  any 
behavior  functions  associated  with  the  modes  of  E.  If  there  is  at  most  one  non-scheduled 
event  in  the  set,  we  simply  schedule  it  Otherwise  we  have  an  unacceptable  circularity  and 
Circularity  Error  is  called  to  deal  with  this. 

ScfceduIeQ«ote4BehavlorF«actioM[2-4] 

ScheduleQuotedBehaviorFunctions  takes  as  argument  an  event  E,  that  is  a  mode  binding 
event  (and.  possibly,  a  twiddle  type  mode  landing  of  a  set  of  individual  mode  binding  events 
that  have  been  coalesced  into  a  single  twiddle  event).  We  make  two  passes  over  the  set  of 
behavior  functions.  The  first  insures  that  the  type,  binding,  and  initialization  events 
associated  with  each  are  scheduled.  On  a  second  pass  we  then  scan  the  binding  event  to 
insure  that  any  quantites  it  requires  get  scheduled  since  the  behavior  functions  may,  of 
course  actually  be  called  during  the  loading  or  compilation  process  once  the  mode  with 
which  they  are  associated  is  in  the  environment 

Circularity  Enror[2-3] 

We  announce  the  offending  events  and  set  SchedulingSuccessful  to  FALSE  unless 
FailOnCircularity  has  been  set  to  false. 

2.3.  Scope  (Scanning) 

This  scope  contains  ScanEvent  the  procedure  that  interfaces  to  the  general  purpose 
analysis  tool  the  three  routines  that  particularize  that  tool  to  the  Package  application,  and 
UuknownAtomError.  the  procedure  used  to  announce  that  unknown  identifiers  have  been 
encountered. 
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Sca«Eve«t[3-l] 

ScaaEvent(E)  is  called  by  ScheduleEvent  after  E  has  just  been  stacked;  the  function  of 
ScanEvent  is  to  determine  those  quantities  that  E  depends  upon  and  insure  their  n^hfriiiiing 
prior  to  (or  concurrent  with)  the  scheduling  of  E.  There  are  two  circumstances  in  which  the 
value  of  event  E  is  to  be  scanned: 

(a)  It  is  a  procedure  (EXPR)  binding  of  a  procedure  that  may  be  called  during  lading;  if  so 
NoteMuslScanValueOfEvent(E)  will  have  been  previously  called  (either  by 
ScheduleBehaviorFunctions[24]  or  by  PackageProcessUserProcedureApplication[3*3D  and  as 
a  result  MustScanValueOfEvent(E)  will  return  TRUE. 

(b)  It  is  not  a  constant  nor  a  procedure,  in  this  case  EvemRequiresScanning(E)  will  return 
TRUE. 

If  E  is  to  be  scanned  we  call  Process  Attribute V alue  with  the  value  of  E  plus  the  three 
procedures  that  particularize  ProcessAttribute Value  to  the  requirements  of  Package. 

PackateHaveUnkiiowuAtoa[3-2] 

This  procedure  will  be  called  by  the  Analyze  tool  exactly  when  it  has  a  FORM  that  is  an 
identifier  not  local  to  the  form  being  scanned  and  not  an  ECL  system  name.  If  its 
argument,  atom,  is  a  global  name,  nothing  need  be  done.  Otherwise  we  must  schedule  the 
Type,  Binding,  and  Initialization  events  for  atom. 

PackaceProcessUserProcedmreApplicatloii[3-3] 

This  procedure  will  be  called  by  the  Analyze  tool  exactly  when  it  has  a  form  that 
represents  p(argl,.„)  where  p  is  an  identifier  that  is  neither  local  nor  an  ECL  system 
procedure  name.  If  p  is  global  nothing  need  be  done  regarding  p.  Otherwise  we  schedule 
the  Type,  Binding,  and  Initialization  events  for  p  and,  further,  note  that  die  value  of  p’s 
binding  must  be  scanned  (as  p  may  be  called  during  loading). 

Following  this,  we  process  the  arguments  of  p  via  the  call  ProcessList(F.args)  as  required 
by  the  Analyze  tool 

PmckageProcessBehaviorFuBCtloas{3-3] 

This  procedure  is  called  by  the  analysis  tool  exactly  when  it  has  a  form  that  represents 
die  first  argument  to  the  ::  operator;  for  each  "evaluated"  behavior  function  providied,  we 
can  ProcessAttributeValue  on  its  arguments.  Note  that  the  processing  of  the  "quoted" 
behavior  functions  is  handled  by  ScheduleQuotedBehaviorFunctions. 

Umk»ow«Ato«Error(3-5] 

The  purpose  of  this  procedure  is  to  announce  the  occurrence  of  identifiers  that  are 
non -local,  not  ECL  system  names,  not  global,  and  do  not  have  associated  Binding  events. 
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The  variables  CurrentScanF.ventAttribute  anrf  CurrentScanEventNamc  are  introduced  by 
ScheduleEvent  exactly  so  that  UnknownAtomError  can  announce  the  sort  of  event  and  the 
name  of  the  entity  whose  value  contains  the  unaccountable  identifier. 


2.4.  Scope<£vents) 

Recall  that  an  Event  is,  essentailly,  a  triple  <Attribute,  Name,  Value>  where  Attribute  is 
(eucept  for  the  special  "ReadyToCompile"  event)  either  "Type",  "Binding",  or 

Tnittglirntwi" 

This  scope  includes  the  procedures  and  descriptors  that  provide  the  behavior  expected  of 
an  Event  plus  three  procedures  concerned  with  mapping  from  an  Event  or  an  EntityName  to 
the  corresponding  (Type,  Binding,  or  Initialization)  event. 


2.5.  Scope(E  vent  Templates) 

An  EventTemplate  is  an  explicit  triple  <Attribute,  Name,  Value>  that  bridges  between 
the  source  of  events  (Le.  the  various  attributes  of  entities  of  modules)  and  an  Event  as 
manipulated  by  Package.  ” 

2.6.  Scope(ModulesA]idEntities) 

This  scope  simply  introduces  the  concepts  of  Module,  Entity,  and  EntityName  plus  the 
mapping  from  an  Entity  to  its  EntityName. 

2.7.  Scopes(SetOfModules,  SetOfEvents,  SetQfEntity Names,  QueueOfEvents, 
StackOfEventEntries) 

These  scopes  provide  the  required  analogies  for  the  Set,  Queue,  and  Stack  types 
manipulated  by  Package. 

2.8.  Scopes(Attrilrate  Values,  TwiddleE vents) 

These  scopes  introduce  the  several  mappings  concerned  with  the  (ELI)  attribute  values 
and  coalescing  a  set  of  mutually  dependent  modes  into  a  single  “twiddle”  event 
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3.  Implementation  of  Package 

As  we  noted  earlier,  we  propose  to  do  two  implementations  of  Package.  The  first  will  be 
a  relatively  simple  implementation  that  basically  provides  os  with  the  means  to  supply 
Package  with  a  set  of  events  and  to  inspect  the  result  of  its  scheduling  of  these  events.  In 
this  first  implementation  efficiency  will  be  of  tittle  concern.  The  second  implementation 
will  be  as  an  integrated  PDS  tool  that  accesses  modules  to  obtain  the  events  and  global 
names  and  produces  a  module  containing  the  result  of  Package.  With  this  implementation 
we  will  be  concerned  with  efficiency  both  in  the  sense  of  the  cost  of  various  operations  and 
in  the  sense  of  attempting  to  minimize  dependence  on  ECL  heap  memory  management 

In  this  section  we  want  to  overview  the  major  implementation  decisions  that  we  shall 
have  to  make;  sections  4  and  5  provide  the  details  for  two  particular  implementations. 

3.1.  The  Source  of  Event  Templates 

The  abstract  model  postulates  Bases  and  PackageaReferenced,  each  a  Set(Module),  as 
supplying  the  templates  for  the  events  to  be  scheduled  and  the  names  of  quantities  presumed 
global.  We  must  choose  a  specific  implementation  for  Set(Module)  and  implement  the  two 
iterations  (a  triple  iteration  over  Bases  and  a  double  interatioc  over  PackagesReferences)  at 
the  beginning  of  the  Package  procedure. 

3.2.  Global* 

Globals  is  postulated  to  be  a  Set(EntityName);  the  required  operations  are  those  of  adding 
an  element  to  Globals  (within  the  body  of  the  double  iteration  in  Package)  and  of  testing 
whether  some  atom  resides  in  Globals  (the  —  atom  IsInSet  Globals  —  construct  appearing  in 
the  procedures  PackageHaveUnknownAtom  and  PackageProcessUserProcedure Application) . 

3.3.  Events 

Events  are,  conceptually,  triples  of  the  form  <Attribute,  Name,  Value>;  a  number  of 
mappings  to  do  with  the  behavior  of  events  are  postulated  in  the  abstract  model  (summarized 
in  Scope(Events)  of  Package).  In  addition.  Package  postulates  Events,  a  Set  (Event),  and 
ScheduledEvents,  a  Queue(Event).  There  are  a  number  of  specialized  iterations  over  Events 
and  the  requirement  that  we  provide  a  mapping  from  an  entity  name  (or  event)  plus  an 
Attribute  (Type,  Binding,  or  Initialization)  to  the  entry  for  the  corresponding  Event  in 
Events. 

We  must  also  be  able  to  add  events  to  the  queue  ScheduledEvents  and  to  determine 
whether  or  not  some  event  is  already  scheduled  (i.e.  is  already  in  the  queue).  Finally,  we 
must  provide  some  means  to  display  the  result  of  scheduling  the  events. 


3.4.  Stack  of  Event  Entries 

The  stack  behavior  of  StackedEvents,  introduced  in  the  abstract  model  as  a 
Stack(EventEntry),  is  implemented  directly  in  the  sense  that  there  are  no  push  or  pop 
operations  involved  but  only  indexing  of  the  stack.  The  single  interface  to  some  possible 
underlying  memory  management  operations  to  insure  that  there  is  sufficient  space  in  die 
stack  is  Increment  (Top)  which  provides  the  index  of  a  new  top  element  superseding  the  old 
Top. 

The  implementation  decisions  are  reflected  in  a  set  of  modules  each  n«nn«H  pi  (shorthand 
for  Package  Implementation)  but  with  differing  partition  specifications.  All  the 
implementation  modules  use  a  module  named  Utilities  which  provides  a  number  of  notations 
for  dealing  with  list  structure  (e.g.  f.argl,  HasOneArgument(f),  and  so  on)  plus  facilities  for 
variadic  arrays,  connections  to  various  PDS  components,  and  so  on.  In  addition,  there  is  a 
module.  PI(Miscellaneous).  It  has  two  scopes  as  follows: 

Scope(AttributeValues) 

Here  an  Attribute  Value  is  defined  as  a  FORM  and  the  several  procedures  that  deal  with 
an  Attribute  Value  as  an  ELI  FORM  are  explicated.  In  addition  the  iterator  that  produces 
each  behavior  function  (Le.  the  FORMS  UFN(Name)  contained  in  the  first  arguments  of  the 
v.  operator  in  some  value  that  is  a  mode  binding  or  a  “twiddle"  binding)  is  defined. 

ScopeCTwlddleEvents) 

Here  the  two  procedures,  MakcSinglcTwiddlcEvent  and  MakeMultipleT widdleE vent,  are 
implemented.  In  addition  we  have  a  definition  of  MakeTwiddleEvent,  a  procedure  called  by 
these  two  procedures  to  force  the  name  change  from  L  to  <~  L  for  each  mode  being 
defined  by  the  twiddle.  This  name  change  is  done  by  the  same  Analyze  tool  that  is  used  to 
scan  the  values  of  events,  but  with  the  three  procedures  that  specialize  the  analysis  tool  to  a 
particular  application  being  those  appropriate  to  this  name  change  application. 

We  observe  that  a  new  procedure,  CompleteT  widdleE  vent,  is  introduced  to  do  whatever  is 
required  to  convert  the  twiddle  value  produced  by  MakeTwiddleEvent  plus  the  (first)  event 
giving  rise  to  the  twiddle  value  to  an  event.  The  details  of  this  are,  of  course,  dependent 
upon  the  implementation  of  events. 


4w  A  Prototype  of  Package 

As  a  first  implementation  of  Package  we  want  a  system  to  which  we  can  submit  a  set  of 
events  and  a  set  of  global  identifiers  and  from  which  we  can  obtain  the  ordered  set  of 
events.  For  this  prototype  system  we  specifically  want  to  avoid  interfacing  to  the  PDS  and 
real  modules,  rather  using  a  set  of  <Attribute,  Name.  Valne>  triples  to  describe  the  events  to 
be  scheduled.  As  outlined  in  section  3,  there  are  four  basic  sets  of  issues  concerning  which 
we  most  make  implementation  choices.  Oar  discussion  will  be  organized  into  four  parts, 
reflecting  these  four  sets  of  issues;  the  corresponding  implementation  choices  are  organized 
into  four  separate  modules  that  will  later  be  merged  with  Package  to  provide  the  complete 
implementation. 

4.1.  The  Source  of  Event  Templates  and  Globals 

As  the  source  of  event  templates  and  globals,  we  propose  to  employ  list  structure.  Thus 
the  Bases  argument  to  Package  will  be  a  list  whose  elements  are  triples  (that  is,  three 
element  lists)  encoding  an  <Attribute,  Name,  Value>  triple.  The  PackageaReferenced 
argument  will  also  be  a  list  whose  elements  .name  the  quantitie  presumed  global 

These  decisions  are  implemented  by  the  module  PI(Entity5onrce  is  Form).  It  contains 
two  scopes,  as  follows: 

4.1.1.  Scope(ModnlesAndEntities) 

We  define  Entity  as  a  FORM,  provide  the  mapping  NameOfEntity(E)  as  E  (the  only  use 
of  this  construct  being  to  extract  the  name  of  a  global),  and  an  implementation  of 
CountEntities  that  counts  the  number  of  elements  in  its  list  argument. 

4.1.2.  Scope(SetOfModules) 

A  Set(Module)  is  implemented  as  a  FORM.  Also,  we  provide  implementations  of  the  two 
iterators  over  a  Set(Modnle)  reflecting  the  decision  that  Bases  be  a  list  of  CAttribute,  Name, 
Value>  triples  and  PackageaReferenced  be  a  list  of  entity  names. 

4.2.  Globule 

A  straightforward  way  to  implement  Globals£et(EntityName)  is  to  use  a  list  of  names. 
Module  Pl(01obals  is  Form)  implements  Globals  as  such. 
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4.3.  Events 

A  natural  way  to  implement  an  event  would  be  to  employ  a  triple  to  encode  the 
Attribute,  Name,  and  Value.  However,  looking  at  the  behavior  required  we  obaerve  that  we 
must,  for  each  event,  be  able  to  set  and  test  a  Boolean  that  determines  whether  the  value  of 
a  particular  event  must  be  scanned  (this  being  TRUE  when  the  event  is  a  procedure  binding 
for  a  procedure  that  may  be  called  during  loading).  We  therefore  choose  a  quadruple 
<Attribute,  Name,  Value.  MustScan>  to  implement  an  Event 

A  straightforward,  but  possibly  inefficient,  way  to  implement  a  Set  (Event)  and  a 
Queue(Event)  would  be  to  employ  a  list  of  Events  with  the  obvious  functions  for 
new  dements  and  testing  for  membership. 

The  above  decisions  are  implemented  in  module  PI(E vents  is  Lists);  a  discussion  of  some 
of  the  details  of  the  implementation  follows. 

4.3.1.  Scope(Events) 

The  implementation  of  an  Event  as  a  quadruple  is  recorded  and  then  the  several  mappings 
dealing  with  events  are  provided.  A  couple  of  these  may  require  comment 

SameEvents[2-12] 

Two  events  are  taken  to  be  the  same  if  they  are  of  the  same  sort  and  name  the  same 
entity. 

CompleteT  widdleEvent(2- 1 3] 

We  choose  to  produce  an  event  whose  attribute  (Twiddle”)  indicates  a  twiddle  event  and 
with  no  name  and  the  twiddle  binding  as  value. 

4.3.2.  Scope(EveutT easplatea) 

Obaerve  that  we  indicate  that  the  scheduling  is  unsuccessful  if  a  given  event  occurs  more 
than  once. 

4.3.3.  Scope(S«tOfEveats) 

A  Set(Event)  is  implemented  as  an  EventSet  that  is  simply  a  list  of  Event  entries.  The 
three  iterators  over  Events  and  the  addition  of  a  new  Event  to  Events  are  straightforward. 
Note  that  by  adding  a  new  Event  at  the  end  of  Events  we  have  opted  to  keep  the  order  of 
Events  consistent  with  the  order  of  the  EventTemplates  provided  by  the  source  of  such. 
Observe  that  there  is  no  explicit  test  for  membership  in  Events  so  that  there  is  no 
implementation  provided  for  $$  E  TalaSet  Events. 


4.3.4.  Scope(QueueOfEvents) 

A  Queue  (Event)  is  implemented  as  an  EventQueue  that  is  simply  a  list  of  Event  entries. 
Hera  we  have  provided  a  print  function  to  handle  pretty  printing  of  the  result  of  scheduling 
a  set  of  events. 

Observe  that  the  membership  test  (Le.  $$  e  IslnQueue  $$  Q)  is  complicated  by  die  fact 
that  the  bindings  for  recursive  mode  sets  are  coalesced  into  a  single  event 


4.4.  Stack  of  Event  Entries 

A  very  straightforward  way  to  implement  a  Stack(EventEntry)  and  the  associated 
procedure.  Increment(Top)  is  to  employ  a  reasonably  large  array  and,  if  Package  requires  a 
larger  stack  than  we  have  provided,  to  break  indicating  an  error.  The  module 
PICStackOfEventEntries  is  Fixed)  provides  such  an  implementation. 

5.  Package  aa  a  PDS  Tool 

Having  done  a  'quick  and  dirty”  implementation  of  Package  that  can  be  used  to  study  and 
assess  the  basic  algorithms  for  scheduling  a  set  of  events,  we  now  turn  our  attention  to  a 
"rear  implementation  as  an  integrated  PDS  tool 

In  order  to  interface  with  PDS  this  variant  of  Package  must  take  as  the  source  of  events 
die  collection  of  entities  and  attributes  supplied  by  a  given  set  of  modules  (Bases);  it  must,  as 
well  produce  a  module  containing  the  results  of  the  packaging.  In  addition,  there  must  be  a 
component  of  Package  that  takes  the  command  supplied  to  PDS  to  invoke  the  Package  tool 
and  decodes  that  command  to  yield  the  two  sets  of  modules  (Bases  and  PackagesReferenced) 
supplying  inputs.  It  must  also  insure  that  the  modules  in  these  two  sets  are  up  to  date  and, 
if  not,  invoke  the  appropriate  tools  to  derive  up-to-date  versions  of  them  before  proceeding 
with  the  packaging. 

In  addition  to  the  constraints  induced  by  the  need  to  interface  with  PDS,  we  must  also 
consider  the  question  of  efficiency  of  the  operation.  By  efficiency  here  we  have  in  mind 
the  usual  space/time  measures  but  we  are  also  concerned  with  the  underlying  storage 
management  mechanisms  of  ECL  and,  for  example,  attempt  to  minimize  the  use  of  heap 
storage  when  possible  to  avoid  the  garbage  collection  costs  that  are  associated  with  the  use 
of  the  heap. 

The  first  four  subsections  following  parallel  those  of  the  previous  two  sections  and  discuss 
the  four  sets  of  implementation  issues  introduced  in  section  3.  The  fifth  subsection  deals 
with  the  remaining  issues  in  interfacing  with  PDS. 


5.1.  The  Source  of  Event  Templates  and  Global* 

A 3  noted  above,  the  source  of  both  event  templates  and  globals  is  the  collection  of 
attributes  of  entities  of  the  modules  of  Bases  and  Packaged  Referenced.  The  module 
PI(EntrtySource  is  Modules)  supplies  the  required  refinements  via  two  scopes: 

5.1.1.  Scopc(ModulesAj>dEn titles) 

The  mapping  from  an  Entity  to  its  name  is  defined  by  the  field  selection  on  "Name"; 
entity  counting  employs  the  standard  PCS  function  TotalEntityCount 

5.0.  Scope(SetOfModules) 

We  implement  a  Set(Module)  as  a  SEQ(Module).  The  triple  iteration  to  produce  each 
EventTemplate,  T,  of  each  Entity,  E,  of  each  Module,  B,  of  Bases  is  then  implemented  as  a 
triple  iteration  over  the  attributes  of  entities  of  modules  of  Bases.  The  details  of  the 
organization  of  entities  and  attribues  in  a  module  and  their  access  and  manipulation  is 
described  elsewhere  and  will  not  be  repeated  here. 

Similarly,  the  double  iteration  to  produce  each  Entity.  E,  of  each  Module,  P.  of 
PackagesReferenced  is  recast  as  an  iteration  over  the  SEQ(Module)  and  then  an  iteration 
over  the  set  of  entities  of  each. 

5.2.  Globals 

The  name  of  each  entity  of  each  module  of  PackagesReferenced  is  placed  in  Globals  and, 
for  each  identifier  of  each  event  being  scanned  that  is  not  a  local  variable,  system  name,  or 
the  name  of  an  event  to  be  scheduled,  we  must  determine  whether  or  not  that  name  is  a 
member  of  Globals.  We  choose  to  use  tide  ECL  built-in  hashing  functions  to  implement 
Globals.  The  module  PI(Globals  is  Hash  Table)  documents  the  refinements  that  result 

5.3.  Events 

Recall  that  there  are  two  collections  of  Events  manipulated  by  Package:  Events  is  a 
Set(Event)  in  which  we  initially  place  each  event  to  be  scheduled  and  ScheduledEvents  is  a 
Quene(Eveat)  that  contains  the  (ordered)  result  of  the  scheduling  of  the  elements  of  Events. 
In  order  to  motivate  our  choices  for  representation  of  these  two  collections,  let  us  review  the 
various  kinds  of  functionality  they  must  support 

IsTypeEveat(E)  —  returns  TRUE  iff  E  is  a  "Type"  event;  similarly  for  IsBindingEvent, 
etc. 

E  IsInQoeue  ScheduledEvents  —  returns  TRUE  iff  E  has  already  been  scheduled  (by 
being  added  to  ScheduledEvents). 

NateMustScanValueOfEveQt(E)  —  insures  that  MustScan V slueOfEvent(E)  subsequently 
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returns  TRUE. 

TypeErentF or(x)  —  (x  being  either  an  Event  or  an  EntityName)  returns  the  Type" 
event  for  z  (or  the  NoUEvent),  and  similarly  for  Bi ndingE ventFor(x) .  etc. 

SameEvents(E,  F)  —  returns  TRUE  iff  E  and  F  are  the  same  events. 

For  Each  TypeE vent  t  in  Events  ...  —  iterates  over  die  Type"  events  in  Events,  and 
similarly  for  "Binding",  etc. 

Add  E  ToQueue  ScheduledEvents  —  insures  that  E  is  in  the  queue  ScheduledEvents, 
following  the  events  already  there. 

We  note  particularly  that  the  predicate  E  IsInQueue  ScheduledEvents  and  the  mapping 
TypeEventFor(x)  (and  its  counterparts  BiadingEventFor(z),  etc.)  may  be  called  many  times 
for  the  event  (in  fact,  each  time  the  event  name  is  encountered  (and  not  local)  when 
we  are  «*n««ng  the  value  of  some  event).  Therefore  these  operations  should  be  particularly 
efficient 

Our  for  implementation  of  the  Set  (Event)  and  Queue(Event)  is  a  table  containing 

an  entry  for  rvch  event  (and.  in  addition,  some  entries  not  actually  used  for  technical 
reasons  discussed  presently).  An  Event  will  then  be  an  index  into  this  table  and  the  entry 
for  a  given  event  will  contain  various  BOOLs  to  record  such  fads  as  MustScanValueOfEvent 
and  IsScheduied.  The  Queue(Event)  will  be  the  same  table  and  there  will  be  an  index  field 
for  each  entry  that  takes  us  to  the  table  entry  for  the  next  event  in  the  queue. 

The  first  entry  will  be  a  dummy  entry  used  only  to  index  the  entry  for  the  first  event  in 
the  queue.  The  table  will  be  partitioned  so  that  the  Type  events  are  in  one  block,  the 
Binding  events  in  another,  and  so  on.  A  collection  of  variables  (e.g.  TypeEventBase, 
BindingEventBaae,  and  so  on)  will  exmode  this  partitioning  of  the  tables. 

In  order  to  quickly  find,  say,  die  Type  event  given  some  name,  N.  we  will  employ,  in 
aiHHitirtn  to  the  table  of  event  rifarriprirmn,  a  hash  table  that  is  entered  with  the  name  of  some 
event  and  provides  a  triple  containing  the  indices  corresponding  to  the  Type,  Binding,  and 
Tnitiaiiratinn  events  with  that  name  (zero  representing  the  NuilEvent). 

The  module  PI(E vents  is  Array)  provides  the  implementation  of  events  as  sketched  above. 
Several  aspects  of  these  implementation  details  probably  require  some  further  comments: 

5.3.1.  Scopc(Eventa) 

We  define  an  Event(3>l]  as  an  INT  (meaning,  of  course,  an  index  into  the  table 
postulated  above  and  to  be  described  presently). 

We  next  introduce  ErentDescriptorf  3-2],  the  table  entry  for  each  event  The  non-obvious 
fields  include 
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TwiddletBOOL  —  TRUE  iff  the  event  results  from  replacing  some  binding  event  (or 
an  element  of  a  set  of  mutually  dependent  mode  binding  events)  by  a  twiddle 
event. 

IgnoretBOOL  —  TRUE  iff  the  event  is  to  be  ignored  (becuase  it  is  a  mode  binding 
event  mutually  dependent  upon  other  mode  binding  events  that  have  been 
coalesced  into  a  twiddle  event). 

NextJNT  —  the  next  event  in  the  resulting  queue,  ScheduledEvents. 

Before  continuing  with  the  other  entities  in  Scope(Events),  let  us  consider  EventSet(S-l] 
in  Scope{SetOfE vents):  EventSet  is  the  mode  of  the  Set(Event)  and  the  underlying 
representation  of  Queue(Event)  as  well.  Its  first  four  components  index  the  first  entry  in 
the  table  describing  the  events  for.  respectively.  Type,  Binding,  Initialization,  and 
ReadyToCompde  events,  thus  encoding  the  partitioning  of  the  table.  The  fifth  entry. 
Events£EQ(EventDescriptor),  is  the  actual  table  of  entries  describing  the  Set(Event)  and/or 
Queue(Event).  The  local  variable.  Events,  will  be  an  EventSet  and  the  variable 
ScheduledEvents  will  be  an  <"EventQueue*">  c  EventSet  (the  base  mode  being  extended  to 
provide  for  a  distinct  print  function  for  the  table  when  it  is  viewed  as  a  Queue(Event)  rather 
than  a  Set(Event)  ). 

With  these  notions  understood,  we  can  now  consider  the  remaining  entities  in  PI(Events 
is  Array). 

5.3.2.  Scope(MasterControl) 

The  declaration  of  E vents: Set(E vent)  in  Package  is  replaced  by  several  declarations,  to 
wit 

EntityCountINT  —  the  total  number  of  entities  in  Bases  (giving  an  upper  bound  on 
the  number  of  Type,  Binding,  and  Initialization  events  that  might  be  added  to 
Events). 

EventaEventSet  SIZE  3  •  EntityCount  +  2  —  The  size  of  (the  Events  component  of) 
Events  is  sufficient  to  accommodate  the  maxi  roam  number  of  each  sort  of  event 
that  may  be  encountered  (Le.  EntityCount)  plus  a  first  entry  used  only  to  find 
the  first  element  of  the  EventSet  when  it  is  viewed  as  a  Queue(Event).  plus  an 
entry  for  the  Ready  ToCompile  event 

TypeEventBaaeJNT 

BindingEventBaaeJNT 

IntializationEventBaseJNT 

ReadyToCompfleEventlNT  —  We  introduce  local  variables  (shared  with  their 
corresponding  entries  in  Events)  that  encode  the  partitioning  of  the  set  of  events. 

CurrentT  ypeEvent  JNT 
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CurrcntBindingEvenfclNT 

CurrentIoitializjtion£ventJNT  —  Three  more  variables  that  indicate  the  current  last 
Type.  etc.,  event  entered  into  Events  are  initialized. 

NameT oEventMajxHASHT ABLE  —  initialize  the  HASHTABLE  that  will  provide  the 
mapping  from  an  entity  (or  event)  name  to  the  Type,  tending,  and  Initialization 
events  for  it 

5.3.3.  Scope(Events) 

IsTypeEvent{3-3] 

IsTypeEvent(E)  is  implemented  as  a  test  on  die  value  E  to  see  whether  it  is  within  the 
partitioning  of  the  table  of  event  descriptors  corresponding  to  a  Type  event  Observe  that 
the  variables  TypeEventBase  and  BindingEventBase  are  introduced  into  the  environment 
(and  appropriately  initialized)  when  Events  is  declared  (see  PackageChanges[2-l]). 

NoteMustScanValaeOfEveBt(3-7] 

The  MustScan  component  of  the  EventDescriptor  in  the  table  of  EventDescriptors 
associated  with  the  variable  Event  is  set  to  TRUE. 

CompleteT  widdleEvent[3- 12] 

CompleteT  widdleEvent(Binding,  E)  is  called  when  the  event  E.  that  is  in 
Stack  cdEventafFirst]  plus  the  events  in  positions  First  to  Top  of  StackedEvents  have  been 
coalesced  into  a  twiddle  binding  (that  is,  the  argument  name  and  Binding).  It  modifies 
event  E  to  be  the  Twiddle  binding  event  and  notes  that  it  and  the  other  mutually 
dependent  events  coalesced  are  to  be  cnsidered  as  scheduled  and.  further,  that  all  but  E  are 
now  to  be  ignored  (because  they  are  together  coalesced  into  the  value  for  event  E). 

5.3.4.  Scope(SetOfEvents) 

EveatIterators{5-2] 

The  iteration  over  Type,  etc.,  sorts  of  events  commences  at  the  first  entry  in  the  table  of 
event  descriptors  component  of  Events  and  proceeds  through  the  entry  that  is  current  for 
that  sort  of  event 

SetOperatloas[5-3] 

Adding  a  new  Type,  etc.  event  corresponding  to  an  EventTemplate,  T,  amounts  to 
incrementing  the  current  index  for  that  sort  of  event  and  installing  an  EventDescriptor  in 
EventsEvents  at  that  position  initialized  with  the  appropriate  Name  and  Value  components 
(the  other  components  being,  appropriately,  the  default  values  for  those  fields).  Also,  the 
NameT oEventMap  entry  for  that  sort  of  event  is  set  to  provide  the  mapping  from  the  event 
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name  to  the  corresponding  index  in  Eventa-Events. 

5.3.5.  Scope(QneueOfEvents) 

PackafeCha»fes(6-l] 

The  declaration  of  ScheduledEventsK)ueue(Event)  is  implemented  by  declaring 
SchednledE vents  to  be  an  EventQuene  shared  with  Events;  also  die  local  variable.  LastEvent, 
is  initialized  to  index  the  last  event  schedaled. 

PiintEventValae{6-3] 

A  BOOL,  normally  TRUE,  that  is  consulted  by  PrintEventQueueElement  to  determine 
whether  the  triple  <Attribute,  Name,  Value>  or  just  the  pair  <Attribate,  Name>  is  to  be 
printed.  The  FALSE  setting  might  be  used  daring  debugging  when  we  want  to  avoid  seeing 
values  and  just  inspect  the  sort  and  name  of  events  in  a  Queue(Event). 

PriatEveatQueaeElenent[6-5] 

Given  an  EventQueue,  Q,  and  index,  i.  into  Q. Events,  and  a  PORT,  P, 
PrintEventQueneElement  prepares  an  appropriate  representation  of  the  triple  <Attribnte, 
Name.  Valoe>  or  the  pair  <Attribute,  Name>  and  outputs  it 

Qneae<6-6] 

Adding  a  new  event,  E,  to  ScheduledE vents  is  implemented  by  adding  the  new  entry  to 
the  thread  that  orders  the  events  in  the  queue  (the  Next  field  of  the  appropriate  entry  of 
EventsJi vents  (nee  ScheduledE  vents.E vents) )  and  setting  the  IsScheduled  bit  to  reflect  the 
scheduling. 

5.4.  Stack  of  Event  Entries 

Here  we  choose  a  variadic  array  to  implement  the  Stack(EventEntry)  and  employ  the 
Extend  operation  available  in  Utilities  to  extend  the  stack  whenever  Increment  produces  an 
index  that  exceeds  the  current  allocation.  The  details  are  presented  in 
PI(StackOfEventEntries  is  Variable). 
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Appendix  B 

A  Family  of  EL  1  Program  Analyzers 


L  Introduction 

There  are  a  number  of  tools  that  need  to  analyze  some  program  construct  in  order  to 
discover  and  assess  the  meaning  of  identifiers  that  occur  free  in  that  construct  Included 
are  the  following  tools: 

-  Package  -  The  Package  tool  has  the  job  of  determining  an  ordering  among 
some  collection  of  program  entities  that  insures  that  a  quantity  is  defined 
before  it  is  used  It  must  therefore  find  all  the  inter-dependencies  among 
some  set  of  programs  entities  as  a  basis  for  determining  an  acceptable 
ordering  (or  finding  that  there  are  inherent  circularities  that  preclude  such 
an  ordering). 

-  Synonym  -  The  Synonym  tool  has  the  job  of  systematically  replacing  all 
occurences  of  some  identifier  (that  refers  to  a  globally  define  variable)  by  a 
new  identifier. 

-  FindUndefinedldentifiers  •  The  FindUndefinedldentifiers  (FUI)  tool  scans  a 
set  of  program  entities  and,  for  each  identifier  that  is  undefined,  reports  on 
that  fact  and  reports  on  the  context  in  which  the  undefined  identifier 
occurred.  The  Package  and  Synonym  tools  deal  with  concrete  (that  is, 
executable)  ELI  constructs  but  the  FUI  tool  must  be  able  to  deal  with 
abstract  constructs  and  appeal  to  a  set  of  analogies  to  "explain"  abstract 
constructs  in  terms  of  certain  (more)  concrete  constructs. 

The  analyzers  required  for  the  three  tools  are,  abstractly,  quite  similar.  They  basically 
do  a  recursive  evaluation  of  a  program  construct  and  maintain  a  stack  of  identifiers  that 
are  local  to  each  context  Upon  encountering  an  identifier  that  corresponds  to  a 
program  variable  they  must  determine  whether  that  identifier  names  a  local  variable,  a 
built-in  ELI  construct,  or  a  global  and  take  file  appropriate  action.  Thus,  it  would 
certainly  be  appealing  to  have  a  single  analysis  tool  that  was  capable  of  doing  all  three 
functions.  Despite  the  similarities,  however,  file  analyzer  required  for  the  FUI  tool  is 
rather  more  complex  than  the  others  since  it  must  detect  those  (abstract)  constructs  for 
which  there  are  analogies  provided  and  it  must  also  deal  with  the  analysis  of  rewrites 


and  keep  account  of  the  match  variables  that  occur  in  their  patterns  and  replacements. 
In  addition,  it  must  keep  sufficient  records  to  enable  reporting  on  the  context  in  which 
some  undefined  identifier  occurs. 

The  strategy  that  we  have  employed  to  develop  the  analyzers  required  is  to  develop 
first  a  single  abstract  analyzer  that  contains  the  basic  logic  required  to  do  the  recursive 
evaluation  of  some  program  construct  We  then  develop  two  distinct  refinements  of  this 
abstract  analyzer.  One  refinement  yields  an  analyzer  that  is  appropriate  for  the  Package 
and  Synonym  tools  and  a  second  refinement  yields  an  analyzer  appropriate  for  the  FUI 
tool.  The  resulting  analyzers  are  called,  by  the  client  tools,  with  a  set  of  procedure 
parameters  that  further  specialize  the  analysis  task  to  the  particular  requirements  of  the 
three  different  tools. 

In  section  2  we  discuss  the  requirements  imposed  by  the  three  client  tools  in  more 
detail.  Secetion  3  provides  an  overview  of  the  several  modules  that  provide  the 
implementation  of  the  analyzer  family  (with  two  members)  within  the  Harvard  Program 
Development  System  (PDS).  Section  4  provides  a  listing  of  these  modules,  including 
detailed  explanations  of  the  various  program  entities  that  are  defined.  The  reason  that 
the  program  entities  (that  is,  ELI  program  text)  and  the  explanations  (that  is,  English 
text)  are  contained  in  the  same  modules  is  that  we  find  that  by  so  doing  it  is  much 
more  convenient  to  keep  the  explanatory  documentation  up  to  date.  That  is,  if  an 
explanation  of  some  construct  is  simply  one  attribute  of  that  construct  it  becomes  quite 
natural  to  modify  the  explanation  at  the  same  time  the  construct  is  modified.  If  on  the 
other  hand,  the  explanation  was  contained  in  a  separate  document  (a  text  file,  say)  it 
has  been  our  experience  that  updating  the  explanation  after  a  change  in  the  entity  it 
explains  often  does  not  occur  in  a  timely  fashion  -  if  it  occurs  at  all.  Merging  of  such 
explanatory  text  with  program  entities  has  been  made  feasible  by  a  recent  change  to  the 
print  tool  in  the  PDS  that  interfaces  it  to  the  Scribe  text  justifier  system.  With  this 
interface,  the  explanatory  text  is  dealt  with  by  Scribe  and  the  program  text  is  produced 
by  a  pretty-printer. 
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2.  The  Client  Tools 

As  noted  above,  the  analyzers  developed  are  to  be  used  by  three  different  client 
tools:  Synonym,  Package  and  FUI.  In  this  section  we  discuss  the  requirements  that 
these  three  tools  impose. 

2.1.  Synonym 

Synonym  has  the  simplest  requirements  of  the  three  clients.  It  has  a  set  of  identifiers 
that  are  presumed  to  name  global  variables  and  a  corresponding  set  (actually,  in  general, 
expressions)  of  names  that  are  synonyms  for  these  global  variable  names.  The  analyzer 
is  to  provide  Synonym  with  each  occurrence  of  a  variable  name  that  is  neither  local  nor 
the  name  of  a  built-in  ELI  construct;  it  will  return  the  name  that  is  actually  to  be  used 
(either  the  same  name  or  a  synonym  for  it). 

2.2.  Package 

The  Package  tool  is  used  to  prepare  a  set  of  program  entites  for  loading  into  an  ELI 
interpretive  environment  and/or  for  subsequent  compilation.  We  can  think  of  it  as 
being  given  a  set  of  so-called  events  and  its  job  is  to  order  the  events  in  such  a  way 
that  if  an  event,  e,  depends  upon  an  event,  f  then  /  proceeds  e  in  the  ordering.  The 
events  can  be  thought  of  as  of  two  types:  binding  and  initialization.  A  binding  event 
associates  some  (global)  name  and  its  value  (an  ELI  expression).  An  initialization  event 
contains  some  ELI  expression  that  is  to  be  evaluated.  Given  some  event,  the  associated 
expression  (that  is,  the  expression  to  which  some  name  is  to  be  bound  or  the 
initialization  expression  to  be  evaluated)  must  be  analyzed  to  determine  those  events  on 
which  the  expression  depends  (for  example,  an  initialization  event  may  include  a 
procedure  call,  say,  ffa),  so  that  both  f  and  a  must  be  bound  and  initialized  before  the 
initialization  event  can  occur).  Since  an  event,  say  /,  in  which  some  event,  say  e, 
depends  may  also  depend  upon  other  events  the  analyzer  may  be  called  recursively. 
Except  for  the  possibility  of  being  called  recursively!  ,  the  task  posed  by  Package  is  very 


*There  are  also  several  technical  problems  to  do  with  handling  recursive  modes  and  with  handling  the 
behavior  functions  associated  with  an  extended  mode,  but  these  are  not  relevant  here;  see  the  description 
of  the  Package  tool  for  further  details. 


similar  to  that  posed  in  Synonym:  given  a  non-local  and  non-built-in  variable  name,  the 
client  tool  must  decide  how  to  interpret  the  variable  names. 

2.3.  FUI 

The  FUI  tool  imposes  the  most  complex  requirements  of  the  three  client  tools, 
although  its  end  result  is  simply  reporting  on  free-variables  that  occur  in  some  program 
construct.  The  complexity  derives  from  the  following  considerations: 

1.  The  FUI  tool  deals,  in  general,  with  abstract  program  constructs  whose 
definition  (implementation)  is  still  pending,  in  order  to  "explain"  such 
constructs,  the  user  may  supply  analogies;  an  analogy  takes  the  form 

pattern  <~>  replacement 

where  pattern  and  replacement  are  ELI  (possibly  extended)  expressions, 
including  the  forms  SS  x  or  7?  x  where  x  is  an  identifier.  If  the  pattern  of 
some  analogy  matches  a  program  construct  being  analyzed,  then  the  analyzer 
is  to  process  the  replacement  part  of  the  analogy  using  the  expressions  that 
matched  the  match  variables  in  the  pattern  for  all  occurrences  of  match 
variables  in  the  replacement.  The  replacement,  with  substitution  of 
expressions  matched  for  occurrences  of  match  variables,  is  called  the 
interpretation  of  the  construct  matching  the  pattern. 

2.  The  program  entities  being  analyzed  may  include  rewrites.  The  analysis  of  a 
rewrite  involves  keeping  account  of  the  match  variables  that  occur  in  the 
pattern  part  so  that  we  can  determine  whether  a  match  variable  occuring  in 
the  replacement  part  is  defined  or  not  and  report  on  those  that  are  not 
Thus,  in  addition  to  the  local  program  variable,  the  analyzer  must  keep 
account  of  the  local  match  variables. 

3.  The  FUI  tool  has,  as  an  option,  reporting  on  all  the  (user)  procedures  called 
by  some  construct  being  analyzed. 

4.  The  FUI  tool,  when  reporting  on  occurrences  of  free  variables,  has  an  option 
of  providing  a  certain  amount  of  context  to  aid  the  user  in  determining  just 
where  to  look  for  some  undefined  variables.  This  context  amounts  to 
indicating  blocks,  loops,  cases,  exprs,  and  so  on  entered  and  providing  an 
indication  of  how  many  statements  within  each  construct  entered  preceed 
that  containing  the  free  variable  occurrence. 


3.  Implementation  of  the  Analyzer  Family 

There  are  five  modules  that  provide  the  basis  for  the  implementation  of  the  two 
member  analyzer  family.  Their  names,  and  a  brief  description  of  each  is  as  follows: 

-  Analyze 

The  definition  of  the  abstract  analyzer  that  is  the  progenitor  of  the  two 
concrete  analyzers  that  have  been  developed.  The  analyzer  defined  by 
Analyze  is  described  using  notations  that  free  the  reader  from  having  a 
technical  understanding  of  the  details  of  the  internal  representation  of  ELI 
program  constructs. 

-  Analyzel(General) 

This  module  contains  several  refinements  that  are  commonn  to  both 
analyzers  being  developed.  By  and  large,  they  have  to  do  with  implementing 
the  abstract  iterators  and  the  likes  used  in  Analyze  in  terms  of  the  actual 
internal  representation  of  ELI  program  constructs. 

-  Analyzel( Application  is  Concrete) 

This  module  contains  the  remaining  (that  is,  thc»e  augmenting  the 
refinements  contained  in  Analyzel(General))  refinements  necessary  to 
produce  the  analyzer  appropriate  for  use  by  the  Package  and  Synonym  tools. 

-  AnalyzeI(Application  is  Abstract) 

The  remaining  refinements  necessary  to  produce  the  analyzer  appropriate  for 
use  by  the  FUI  tool 

•  ListUtilities 

A  collection  of  (general  purpose)  utilities  useful  for  dealing  with  the  list 
structure  internal  representation  of  ELI  program  constructs 

The  derivation  of  the  two  concrete  modules,  denoted  ANLZQ3]  and  ANLZA[3]  for 
the  concrete  and  abstract  applications,  respectively  is  depicted  below. 


Analyze 


Analyze(General) 


AnalyzeI(Application  is  Concrete)  Analyze(l] 


Merge 

AN! 

LZQ2] 

Concretize  | 

1 

ANLZQ3] 


AnalyzeI(Ap  plication  is  Abstract) 

/' 


ANLZA12] 


Concretize 


ANLZA(3] 


I 
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<  Analyze  a  56,  AnalyzeKApplication  is  Abstract)  •  61, 
AnalyzeKApplication  is  Concrata)  a  40, 
AnalyzeKGenaral)  a  34  > 


1  Module 
Comment 


The  main  procedure,  named  ProcessExpression,  basically  does  a  recursive  evaluation  of 
some  program  construct  (for  example,  a  procedure,  a  mode  definition,  or  the  like)  and 
maintains  a  stack  (named  NameStack)  of  names  of  variables  that  are  in  the  local 
environment  in  each  context. 

The  client  tool  interface  is  via  a  procedure  named  ProcessAttributeValue  to  which  the 
client  supplies  the  program  construct  to  be  analyzed  plus  several  procedures  that  tailor 
the  analysis  to  his  application. 

EndComment; 

Module  has  Uses(UstUtilities>, 


+++++  NameStack  +++• 


2-1  Scope 
Comment 

This  scope  provides  the  several  modes,  data  objects,  and  procedures  required  to  set  up 
and  manipulate  NameStack,  the  stack  of  names  of  variables  that  are  local  to  the  current 
FORM  being  processed  by  ProcessExpression. 

EndComment; 

Scope  has 

ExportedSyntax(EquatePhrases(TorEachRelevantName$tackEntry  H  j*, 

TOR  IS  Ph 


Analogies 

(ForEachfielevantNameStackEntry  IS  j  REPEAT  T?  body  END)  <}> 
REPEAT  DECt  IS  j:INT;  ??  body  END; 

EndAnalogies; 


2-2  NameStack 
Comment 

The  NameStack  is  implemented  as  a  pointer  to  a  sequence  of  entries  so  that  the  stack  can 
be  extended  if  the  initial  size  estimate  (provided  by  NameStackSize  below)  proves  too 
modest. 


EndComment; 
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CONST(FTR(SEQ(NameStackEntry))  BYVAL 

ALLOC(SEQ(NameStackEntry)  SIZE  NameStackSize)H 


2-3  NameStackSiza  <-  CONSTANT  BYVAL  100)s 


2-4  NameStackEntry 

NameStackEntry  isa  Struct(Name:FOPM)  — 

Different  refinements  may  choose  to  provide  for  a  variety  of  fields,  but  we  assume  that  all 
will  provide  a  field  named  Name  to  store  the  variable  name. 


2-5  NP 
Comment 

M*  will  index  the  current  topmost  position  on  NameStack. 
EndComment; 

NP  <-  CONST(INT)! 


2-6  PushLocalName 
Comment 

Provision  is  made,  through  ExtencKNameStack)  to  extend  the  name  stack  if  it  proves  to  be 
too  small. 

EndComment; 

PushLocalName  <- 
EXPRfName^ORM) 

BEGUN 

Is  Identified  Name}  +>  NonAtomicName(Name>, 

(NP  <-  NP  +  1)  GT  LENGTH  NameStack)  -> 

Extend(NamaStackfc 

NameStack[NP]  <-  CONST(NameStackEntry  OF  Name); 

END; 


2-7  NonAtomicName 

NonAtomicName  isa  ProcedurefNamesFORM)  — 

A  non  identifier  is  about  to  be  pushed  onto  the  name  stack. 
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2-8  IsLocalNama 


Comment 

Different  refinements  may  choose  to  partition  tha  nama  stack  in  various  ways  and  tha 
abstract  itarator  ForEachReievsntNameSteckEntry  j  -  will  ba  refined  to  raflact  such 
partitionings. 

EndCommant; 

IsLocalNama  <- 
EXPRtatoircFORMl  BOOL) 

«  BEGIN 

ForEechRefevantNameStackEntry  j 
REPEAT 

NameStack[j]Aiame  -  atom  *>  RETURNdRUE); 

ENDt 

FALSE; 

END; 


■M- 


+ 


BasicProcsasing  . »+■ . in* 


3-1  Scops 
Scops  has 

ExportodSyntaxtPREFIXOntarpran,  INFTXCas"), 

EquatePhrasasfForEachDECLEIement  IS  d  in  IS  F, 
TOR  IS  d  FROM  N  f), 

EquataPhrasas(TorEachLocalNama  II  n  in  II  c T, 

TOR  II  n  FROM  IS  <f), 

EquatsPhrasas(TorEachCASEArm  II  a  in  II  F, 

TOR  II  a  FROM  II  F), 

EquataPhraaas(TorEachControlQamant  II  a  in  II  a', 
TOR  II  a  FROM  II  s’), 

EquatePhrasesfForEachlterstorElement  H  a  in  It  F, 
TOR  II  a  FROM  II  F\ 

EquataPhrasasCForEachSTRUCTModa  dm  in  II  S', 
TOR  II  m  FROM  H  S’), 

EquataPhrasasFForEachStatamant  Ms  in  It  L\ 
TOR  »  s  FROM  M  LT, 

EquatePhrasesTForEachFormeiMode  II  m  in  M  F, 
TOR  Mm  FROM  M  f\ 

EquatsPhraaesFForEachFormai  M  d  in  M  F, 

TOR  M  d  FROM  M  f*))i 


3-2  ProcsasExprstsion 
Comment 

ProceeeExpression  does  a  recursive  evaluation  of  its  argument,  maintaining  in  NsmeStack 
tha  sat  of  variable  names  local  to  tha  currant  context  Tha  paragraphs  following  describe 
tha  processing  of  tha  various  constructs  dona  by  ProcsssExpression. 
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Qv*n  a  constant  argument  ProcosaExprassion  exits  immediately. 

If  f  is  an  identifier,  then  we  proceed  as  follows:  if  f  names  a  system  procedure  or  is  a 

local  variable  we  exit  immediately.  Otherwise  the  user  supplied  procedure, 
HevellnknownAtom,  is  called  to  deal  with  the  situation.  (For  example,  it  might  consult  some 
table  of  global  names  to  attempt  to  resolve  the  identifier  ocurring,  reporting  that 
undefined  if  it  was  not.) 


Otherwise  ,  the  argument  f  is  an  expression;  we  do  a  case  analysis  of  its  operator  (tap)  to 
determine  the  ELI  construct  that  we  have.  Comments  on  several  of  the  possibilities 
follows: 


BEGIN:  We  do  the  bookeeping  appropriate  to  enter  a  new  block  (for  example,  record 
the  currant  NameStack  top  so  that  it  can  be  restored  at  the  end  of  the  block),  process 
each  statement  of  the  block  (recursively),  and  then  do  the  boo  keeping  appropriate  to 
block  exit. 


DECL:  The  mode  and  specification  for  each  (parallel)  declaration  element  are  processed 
and  then  the  names  declared  by  each  declaration  element  are  pushed  onto  NameStack. 

CASE:  We  recall  that  in  ELI  the  CASE  statement  takes  the  general  form 
t  —  CASE(Re»ationfll  _)[Argument[l],  _] 

Controlfk,  11  _,  Controlfk,  n]  ->  Result[kJ 

END; 


where 

Control[k,  j]  — 

[Test[kJ,  11. _,  [Test[k,  j,  m]]Predicate[k,  j] 


The  processing  of  the  CASE  is  as  follows: 

1.  Process  the  list  of  relations  (Relational  _).  Here  ProcessList(L)  is  shorthand  for 
iterating  over  each  element,  a,  of  the  list  L  and  calling  ProcessExpression(eX 

2.  Process  the  list  of  arguments  (Arguments  1  _). 

3.  For  eech  arm  of  the  CASE,  say  the  x-th,  process  eech  control  element,  Control[k, 
il  and  then  process  the  result,  Result[kl  The  processing  of  Control[k,  J]  involves 
processing  the  list  of  tests  (Testfc,  j,  11  _)and  then  processing  the  predicate, 
Predicate[k,  jl 


FOR:  Recall  that  the  general  form  of  a  for  statement  is  f  •— 
FOR  var  FROM  low  BY  delta  TO  high  REPEAT  body  ENO 
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We  can  think  of  the  construct  as  consisting  of  a  sequence  of  "Iteration  elements"  ,  f  — 
(el,  e2,  _)  where  el,  e2,  -  are  (FOR  var),  (FROM  low),  and  so  on.  For  present 
purposes  there  are  three  types  of  such  elements  corresponding  to  the  following  three 
predicates: 

lslteratorVariabieSpec(e>:  Here  we  have  e  —  (FOR  ver)  and  we  process  it  by 
capturing  the  variable  name,  var,  to  be  pushed  onto  the  name  stack  just  before  we 
process  the  body  of  the  loop. 

teSody(e):  Here  a  (REPEAT  body);  we  do  the  bookeeping  appropriate  for  entering 
a  loop,  push  the  iteration  variable  name,  if  any,  onto  the  name  stack,  process  each 
statement  in  the  body,  and  then  do  the  bookeeping  appropriate  to  exiting  the  loop. 

Otherwise  (here  e  —  (FROM  low),  and  so  on)  we  process  the  specification  (low,  and 
so  on). 


s  :  Here  we  have  f  —  spec  a  UR.  If  the  first  argument  (spec)  specifies  user  behavior 
then  tha  user  supplied  procedure,  ProcessBehaviorFunctions,  is  called  to  deal  with  the 
specification;  otherwise  PsocessExpression  is  called.  Finally  the  second  argument  (UR) 
is  processed. 


EXPR:  We  do  the  bookeeping  appropriate  to  entering  an  EXPR  and  then  process  the 
mode  and  specification  of  each  formal  parameter.  Following  this,  we  push  the  names  of 
the  formats  onto  the  name  stack  and  process  the  result  mode.  We  then  do  the 
bookeeping  appropriate  to  entering  the  body,  process  the  body,  and,  finally,  do  the 
bookeeping  appropriate  to  exit  the  body  and  then  the  EXPR  as  a  whole. 

Otherwise  (that  is,  f  is  not  one  of  the  ELI  consructs  that  requires  special  processing) 
we  proceed  as  follows: 


1.  If  the  construct  does  not  have  the  form  g(al,  _)  with  g  an  identifier,  then  we 
simply  process  each  element  of  f. 

2.  If  we  have  f  —  g(al,  _>  where  g  names  a  system  procedure,  then  we  rail 
ProcessSystemProcedureAppI  ication. 

3.  Otherwise  (that  is,  f  —  g(al,  _)  with  g  naming  a  user  procedure)  we  call 
ProcessUserProeedureAppiication. 


EndComment; 

Process  Expression  <- 
EXPWrFORM;  FORM) 

BEGIN 

IsConstsnt(f)  -»  f; 

IsIdentifieKf)  -> 

BE9N 

leSy*temProcedure(0  OR  IsLocalName(f)  ->  f; 
HeveUnknownAtom(f); 

END; 
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CASE[f.op] 

["BEGIN*]  -> 

BEGIN 

EnterBlock(f>i 
ForEachStatement  s  in  f 
REPEAT  ProcassExpression<s}  END; 
LaaveBlockO; 
ft 

END: 

[-DEC1/]  -> 

BEGIN 

ForEachDECLElement  d  in  f 
REPEAT  ProcesaModeAndSpacFoKd)  END: 
ForEachDECLElament  d  in  f 
REPEAT 

ForEachLocalNama  n  in  d 
REPEAT  Pu«hLocalName(n)  END: 

END; 

ft 

END; 

[■STRUCT]  -> 

BEGIN 

ForEachSTRUCTMode  m  in  f 
REPEAT  ProcessExpression(m)  END; 
ft 

ENO; 

[V]  ->  ProcessExprassiorKf  jrglh 
["CASE*]  -> 

BEGIN 

ProcossUsttf.CASERelations); 

ProcessListtf.CASEArguments); 

EnterCASE<f); 

ForEaehCASEArm  a  in  f 
REPEAT 

ForEachControlElament  a  in  ^Control 
REPEAT 

Proca*aLi*t(a.Tests): 

Proce«Expres«ion(e.Predicate); 

END: 

Proce**Expression(aJ?e«ult); 

END: 

LaavaCASEO, 

ft 

END; 

[TOR-]  -> 

BEGIN 

DECL  NamatFORM; 

ForEacWteratorDemant  a  in  f 
REPEAT 
BEG3N 

WtaratorVariablaSpada)  -> 

Name  <-  eJteratorVariable; 
lsBody(e)  -> 

BEGIN 

EhtsrLoop<f)i 

Name  *  ML  ->  PuahLocaiNama(Nama)} 
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ForEachStatemant  s  in  a 
REPEAT  ProcessExpression(s)  ENDs 
LaavaLoopO; 

END; 

Proce*sExpression<e.Spec); 

END; 

END; 
f J 

END) 

fCONSri  fALLCXT]  -> 

0  ProcessModeAndSpecFor<f);  f  (J 
[*r.*]  -> 

BEGIN 

BEGIN 

Specif  iesUsarBehavior<f.argl)  -> 
ProcessBehavior  Functions<f  .arg  1 Y, 
ProcessExpression<f  .arg  1  >•, 

ENDj 

Proca*sExpression(f.arg2>! 

U 

END; 

[-PROC*]  -> 

BEGIN 

ForEachFormalModa  m  in  f 
REPEAT  ProcassExpressiortfm)  ENCfc 
Process  Exprasaion(fjrg2); 

f } 

END; 

["EXPR"]  -> 

BEGIN 

EnterEXPR(f); 

ForEachFormai  d  in  f 

REPEAT  ProcessModaAndSpecFor<d)  END; 
ForEachFormai  d  in  f 
REPEAT  PushLocalName(d.Name)  END; 
ProcesaExpressionffJtesuJtModa); 
EnterEXPRBodytf); 
ProcaaaExprasaion(f^ody)s 
LeeveEXPRBodyO; 

LaavaEXPRO; 

fl 

END; 

[-«•]-> 

BEGIN 

HaaOnaArgumant(f)  -> 

Q  ProcasaExprasak>n<fjirgl);  f  (1 
BEGIN 

fjrglnp  -  “<"  OR  fjrglnp  -  "QL"  -» 

Pr  oca*aUst(f.arg  l.arga); 
ProcaaaExpraaaion<f  .arg  1 Y, 

END; 

ProcetaExprassion(f.arg2); 

f; 

END; 

r/*i  nn  -> 

BEGIN 
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HaeOneArgument(f)  ■>  b 
Pr  ocessExpressiorKf.argl); 
fj 

END; 

[■*/’]  ->  [)  ProcessExpression<f.arg2);  f  <i 
TRUE  •> 

BEGIN 

DECL  op:FORM  LIKE  f.ops 
Isldentifier(op)  •>  [)  ProcessList(f);  f  (1 
lsSystemProcedure<f.op)  -> 
ProcessSystemProcedureApplication(f); 
ProcessUserProceduraApplication<f); 

END; 

EM3( 

END; 


3-3  Isldentifier 

Isldentifier  isa  Procedure<f:FORM;  BOOL)  — 
Returns  TRUE  iff  f  is  an  identifier. 


3-4  Is  Constant 

IsConstant  isa  Procedure<f:FORM;  BOOL)  — 
Returns  TRUE  iff  f  is  an  constant. 


3-5  ProcessList 
Comment 

ProcessList(L)  is  shorthand  for  iterating  over  the  elements,  e,  of  L  and  calling 
ProcessExpression(e)  on  each. 

EndComment; 

ProcessList  <- 
EXPRtLFORM) 

ForEachListElement  e  in  L 
REPEAT  ProceesExpressiorKe)  ENO; 


3-6  ProcessAttributeValue 
Comment 

ProcessAttributeValue  provides  the  user  interface  to  the  analysis  tool.  It  is  called  with  the 
folowing  arguments: 


Value  -  the  FORM  to  be  analyzed 

HaveUnknownAtom  -  the  procedure  to  be  called  when  the  analyzer  has  an  identifier 
that  is  not  a  system  name  nor  s  local  variable. 
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ProcessUserProcedureApplication  -  the  procedure  to  be  catted  when  the  analyzer  has 
the  construct  f  «  g(al,  _)  and  g  is  an  identifier  that  is  not  a  system  name. 

ProcessBehaviorFunctions  -  the  procedure  to  be  catted  when  the  analyzer  has  the 
construct  f  ■»  spec  a  UR  and  spec  has  the  form  <shortname,  _>  to  process  spec. 

ErrorPort  -  the  PORT  to  which  error  comments  are  to  be  directed 


EndComment; 

ProcessAttributeValue  <- 
EXPR(Value:FORM, 

HeveUnknownAtom:PROC(FOR^  FORM),  , 
ProcessUeerProcadureApplicatlon:PROC<FORM;  FORM), 
ProcessBehaviorFunctions  :PROC(FORM), 
ErrorToUserrfJROC<STRtNG,  FORM,  STRING)) 

[)  InitializeNameStackO;  ProcessExpressiorKValue)  (J 

Analogies 

InitializeNameStacKO  <}>  NOTHING; 

EndAnalogies; 


3-7  HaveUnknownAtom 

HaveUnKnownAtom  isa  ProeeduretatorwFORM;  FORM)  — 

HaveUnknownAtom  is  a  procedure  supplied  by  the  user  on  a  call  to  ProcessAttributeValue 
to  tailor  Process  Expression  to  his  application.  It  is  called  when  ProcessExpression  has  an 
unknown  identifier  (that  is,  one  that  is  not  a  system  name  or  a  local  variable  name). 

Analogies 

InitiaiizeNameStackO  <}>  NOTHING; 

EndAnalogies; 


3-8  ProcessUserProcedureAppiication 

ProcessUserProcadureApplieation  isa 
ProcedureO-KlRM;  FORM)  - 

ProcesaUserProcedureApplication  is  a  procedure  supplied  by  the  user  via  his  call  on 
ProcessAttributeValue  to  tailor  ProcessExpression  to  his  application.  It  is  called  when  f  — 
fn(  al,  an)  and  fn  is  an  identifier  that  does  not  name  a  system  procedure 


3-9  ProcessBehaviorFunctions 

ProcessBehaviorFunctions  isa  Procedure^ :FORM)  — 

ProcassSehavorFunctions  is  a  procedure  supplied  by  the  user  via  his  call  on 
ProcessAttributeValue  to  tailor  ProcessExpression  to  his  application.  It  is  called  when  f  — 
<  Short  Name,  UFl(Nl),  _  >  (the  left  hand  side  of  a  s  operator) 
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3-10  ErrorToliser 
ErrorToUsar  isa 

Procadure<Left  STRING,  f-JORM,  Right.-STRING)  - 

Used  to  communicate  a  problem  to  the  user;  Left  and  Right  typically  comment  on  some 
problem  with  the  FORM  f  being  processed. 


»+->++++"M-»++++++  ProcessModeAndComponentsSpecified  +++++++++  +  ♦♦  +++* 

4-1  ProceesModeAndSpecFor 

ProcessModeAndSpecFor  isa  Procedure(d:FORM;  FORM)  — 

Hera,  d  —  varsand  BC  spec[l],  _  or  d  —  constfmd  9C  spec(ll  _)  (where  const  is  CONST 
or  ALLOC). 

Process  the  md  and  the  spec[j]. 


*+*■*+■*■  » ¥^***++*****+  Statementlteration  ++++++++++ 

5-1  Scope 
Analogies 

(ForEachStatement  M  s  in  <|  f  REPEAT  ??  body  END)  <}» 
REPEAT  OECL  H  s:F0RM  SHARED  tt  f;  ft  body  END; 

EndAnalOgies; 


♦+■» ++ * «•+ ■»♦»♦»»♦■>♦»♦♦♦♦  + + ProcassBEGlN  »♦+♦++  »+»++< 

6-1  EnterBlocK 

EnterBlock  isa  Procedure(f  fORM)  — 

Do  the  record  keeping  appropriate  to  entering  a  block. 


6-2  LeaveBlock 

LeaveBlock  isa  ProcedureO  — 

Do  the  record  keeping  appropriate  to  block  exit  (including  restoring  the  NameStack). 
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7-1  Scop* 

Comment 

The  FORM  being  processed  is 

f  —  DECL  xl,  yl,  —  md[l]  BC  spec[l] 

DECL  xn,  yn,  _;md[n]  BC  spec(nj 


EndComment; 


7-2  Iterator 
Analogies 

(ForEachOECLElement  It  d  in  It  f  REPEAT  *?  body  END)  <}> 
REPEAT  DECL  II  d:FORM  SHARED  II  f j  7?  body  END} 

(ForEachLocalName  IS  n  in  II  d  REPEAT  ff  body  END)  <}> 
REPEAT  DECL  II  mANY  LIKE  II  d;  ??  body  END; 


EndAnalogies; 


ProcessSTRUCT 


8-1  Scope 
Analogies 

(ForEachSTRUCTMode  II  m  in  II  f  REPEAT  ??  body  END)  <}> 
REPEAT  DECL  II  m:FORM  LIKE  II  f;  V.  body  END; 


EndAnalogies; 


ProcessCASE 


9-1  Scope 
Comment 


*- 


f  CASE(Relation[ll  _){Argument[ll  _] 
Control[k,  lj  Controi[K,  n]  ■>  Result[Kj 
END 
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EndComment; 


9-2  Iterator 
Analogies 

(ForEachCASEArm  tl  a  in  $S  f  REPEAT  V.  body  END)  <}> 
REPEAT  DECL  tl  a:FORM  SHARED  tl  f;  V.  body  END; 

(ForEachControlEJement  II  e  in  (||  a).Control 
REPEAT  V.  body  END)  <}> 

REPEAT  DECL  II  e#ORM  SHARED  tl  a;  V.  body  END; 
EndAnalogies; 


9-3  EnterCASE 

EnterCASE  isa  Procedure(f:FQRM)  — 

Do  the  bookeeping  appropriate  to  entering  a  CASE  statement. 


9-4  LaaveCASE 

LeaveCASE  isa  ProcedureO  — 

Do  the  bookeeping  necessary  to  leaving  a  CASE  ststement. 


Processlterator 


10-1  Scope 
Analogies 

(ForEac  WeratorElament  II  e  in  tl  f  REPEAT  ??  body  END)  <}> 
REPEAT  DECL  II  e:F0RM  SHARED  tl  f;  V.  body  END; 

lslteratorVariableSpec(ll  s)  <}>  tl  s; 

hBodydl  b)  <}>  tl  b; 

EndAnalogies; 


10-2  EnterLoop 

EnterLoop  isa  ProcedureO  — 

Do  the  bookeeping  appropriate  for  entering  a  loop. 


-■*>1 
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10-3  LeaveLoop 

LeaveLoop  isa  ProcedureO  — 

Do  the  bookeeping  appropriate  for  returning  from  a  loop. 


■>  ♦  ++»+♦+■ 


+-M-++ 


ProcassDoublaColon 


11-1  Sped  fiasUsar  Behavior 

SpacifiasUsarBahavior  isa  Proeadure<f:FORMj  BOOL)  — 
Returns  TRUE  iff  f  —  <  ShortNama,  UFl(nl),  _>. 


ProcassPROC 


12-1  Scope 
Analogies 

(ForEachFormalMode  fS  m  in  It  f  REPEAT  7f  body  END)  <}> 
REPEAT  DECL  S3  mtFORM  SHARED  33  f;  TTbody  END; 

EndAnaiogies; 


►+++-M-* 


*•+++++  ProcessEXPR 


13-1  Scope 
Analogies 

(ForEachFormal  It  h  in  33  f  REPEAT  Tf  body  END)  <}> 
REPEAT  DECL  31  h:FORM  SHARED  33  f;  V.  body  END; 

EndAnaiogies; 


13-2  Enter EXPR 

EnterEXPR  isa  Procadure(ffORM)  — 

Do  the  boo  keeping  appropriate  for  entering  an  EXPR. 


13-3  LeaveEXPR 

LeaveEXPR  isa  ProcedureO  — 

Do  the  bookeeping  appropriate  for  returning  from  an  EXPR. 
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13-4  EnterEXPRBody 

EnterEXPRBody  isa  Procedure<f:FORM)  — 

Do  the  bookeeping  appropriats  to  entering  the  body  of  a  procedure. 


13-5  Leave  EX PRBody 

LaaveEXPRBody  isa  ProcedureO  — 

Do  the  bookeeping  necessary  to  leave  an  EXPR  body. 


♦  »+♦»+♦++♦♦»♦*+  *****  +■  *  h  SystemNames 

14-1  IsSystemProcedure 

IsSystemProcedure  isa  ProcadurefatomtFORM;  BOOL)  — 

Returns  TRUE  iff  atom  names  an  ELI  system  procedure. 


14-2  ProcessSystemProcedureApplication 

ProcessSystemProcedureApplication  isa  ~ 

Procedure{f:FORM;  FORM)  - 

tt  has  been  determined  that  f  has  the  form  f  —  P(al,  _)  where  P  names  a  system 
procedure;  do  the  processing  appropriate^ 
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1  Module 
Comment 


Thera  are  severe!  issues  in  developing  an  analyzer  appropriate  for  use  by  the  FU  tool: 

(a)  The  program  constructs  being  analyzed  include,  in  general,  abstract  constructs  not 
defined  in  base  EL1.-I  The  user  may  supply  various  analogies  to  ‘explain1*  certain  of 
these  abstract  constructs,  if  so,  the  analogies  are  to  provide  the  basis  for  interpreting 
each  instance  of  the  abstract  construct  We  therefore  need  to  provide  mechanisms  to 
discover  when  some  construct  that  is  being  analyzed  has  a  corresponding  analogy  and 
to  interpret  the  abstract  construct  in  accordance  with  the  analogy. 

(b)  The  entities  being  analyzed  may  include  rewrites.  If  so,  we  must  analyze  the 
replacement  part  Knowing  what  match  variables  have  been  defined  in  the  pattern  part. 
The  bookeeping  of  match  variables  is  rather  similar  to  bookeeping  the  current  set  of 
local  variables.  We  will  employ  the  NameStack  for  both  kinds  of  bookeeping, 
partitioning  it  appropriately  to  permit  lookup  of  either  kind  of  variable. 

<c}  The  FU  tool  needs,  in  addition  to  the  fact  that  some  variable  name  occurs  free, 
sufficient  information  to  report  to  the  user  the  context  in  which  the  free  variable 
occurred.  For  this  purpose  we  will  maintain  a  control  stack  and  retain  in  that  stack  the 
contextual  information  required.  This  stack  will  have  an  entry  for  each  block, 
procedure,  loop,  and  so  on  entered. 


EndComment; 

Module  has  lises<Analyze,  Utilities); 


NameStack 


2-1  Scope 
Comment 

A  major  difference  in  the  analyzer  for  FUI  and  the  one  for  Package  and  Synonym  is  that 
we  wilt  have  a  control  stack  (named  ControlStack)  that  will  record  the  control  structures 
entered  and  not  yet  exitted  Also,  we  will  keep  on  the  NameStack  the  match  variables 
currently  known  (in  addition  to  the  local  variables). 


EndComment; 


2-2  ControlStack  <- 

CONST(PTR(SECXControlStackEntry))  BYVAL 

AlLOC(SEQ(ControlStackEntry)  SIZE  ControfStackSize)); 

2-3  ControfStackSize  <-  CONSTANT  UKE  40); 
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2-4  ControlStackEntry 
Comment 

The  fields  of  a  control  stack  entry  are  interpreted  as  follows: 

Type  -  the  type  of  entry,  among  which  are  "Block’,  "Loop",  "EXPR",  "EXPRBody", 
"Rewrite",  "Interpretation”,  and  so  on. 

NP  -  the  name  stack  index  current  when  the  control  context  wes  entered, 
f  -  the  FORM  being  analyzed  in  the  current  context. 

StatementCount  -  counts  the  statements  in  a  block  or  loop  in  order  to  provide  the 
client  tool  information  necessary  for  reporting  on  the  context  of  a  free  variable 
occurrence. 

EndComment; 

ControlStackEntry  <- 

STRUCKTypetSYMBOL,  NPdNT,  f:FORM,  StatementCountdNT); 

2-5  CP 
Comment 

CP  will  index  the  current  top  of  the  control  stack. 

EndComment; 

CP  <-  CONSTONT); 

2-6  NameStackEntry 
Comment 

In  addition  to  the  Name  field,  we  add  a  field  (named  Binding)  to  permit  association  of  match 
variables  of  analogies  and  the  constructs  that  they  match. 

EndComment; 

NameStackEntry  <-  STRUCT ( Name :FORM,  BindingrFORM); 

2-7  PushNameAndBinding 
Comment 

A  variant  on  PushLocalName  that  pushes  both  a  name  and  an  associated  binding  onto  the 
NameStack. 


EndComment; 
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PushNsmeAndBnding  <- 
EX PR( NamerFORM  BYVAL,  BindingiFORM) 

«  BEGIN 

IsIdentifiaKName)  +>  NonAtomicNameflName); 
(NP  <-  NP  +  1)  GT  LENGTVKNameStack)  -> 
ExtencKNameStack); 

NameStackfNP]  <- 

CON$T(NameStackEntry  OF  Name,  Binding^ 
END; 


2-8  lterator(*> 

Comment 

The  iteration  over  the  "relevant1'  entries  in  the  name  stack  (that  is,  the  entries 
corresponding  to  local  variables)  is  implemented  by  consulting  the  control  stack  to 
determine  those  ranges  of  NameStack  indices  that  are  associated  with  local  variables 
(rather  than  match  variables).  To  simplify  the  loop  a  "guard"  entry  is  installed  above  the 
current  topmost  entry  on  the  control  stack;  ail  ccustructs  that  push  entries  onto  the 
control  stack  an  obliged  to  insure  that  there  is  room  for  the  guard. 

EndComment;  _ 

Rft  w  ritss 

(ForEachReievantNameStackEntry  St  j  REPEAT  7t  body  END )  <-> 

BEGIN 

ControlStackfCP  +  1] «- 
CONST(ControlStackEntry  OF  NIL,  NP); 

FOR  c  FROM  CP  BY  -  1 
REPEAT 

c  -  0  ->  FALSE; 

Local  Name*Type(ControlStack[c].Type)  -> 

-OR  St  j  FROM  ControlSt«ck[c  +  13JMP  BY  -  1 
TO  ControiStack[cJNP  +  1  REPEAT  ??  body  END; 

ENO; 

END; 

EndRewrites; 


2-9  Local  Names  Type  <- 

MACROdype  SYMBOL;  BOOO 
Type  e  "Rewrite"  AfC  Type  e  "Interpretation"; 


it  1 1  ♦♦♦■»♦»♦■«-» »»+  Basic  Processing  t-M- 

3-1  ProcessExpressionChanges(e) 

Comment 


There  are  two  changes  that  are  required  to  adapt  ProcessExpression  to  be  appropriate  for 
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the  Fin  application.  First,  we  must  consider  the  possibility  that  there  is  some  analogy  for 
the  FORM,  f,  being  analyzed  that  provides  an  Interpretation  that  ia  to  be  analyzed  ir  Ifu  of 
f.  Second,  the  (descriptor)  constructs  Struct(_)  and  KnownFreee(_)  are  to  be  analyzed 
exactly  like  STRUCK-)  and  the  constructs  MACRO(-)_  and  Procedural- )_  analyzed 
exactly  like  EXPR(-)- . 

EndComment; 

Rewrites 

BEGIN 

IsConstant(f)  •>  fj 
lsldentifier(f)  <■>  SS  ij 
TT  tail; 

END  <-> 

BEGIN 

lsCon$tant(f)  ■>  f; 

DECL  Tdnterpretation  UKE  FindlnterpretationFor(f>, 

T  •  Nulllnterpretation  ->  Interpret  f  as  T; 
lsldentifier(f)  -»  SS  i; 

TT  tail; 

ENDS 

CASE[— ] 

AT  head;  _ 

[T3ECLT  -»  SS  d; 

AT  middle!; 

[’STRUCT]  ->  SS  s; 

AT  middle2; 

[-EXPR-]  ->  SS  e; 

A?  tail; 

END  <-> 

CASE[_] 

A?  head; 

["DECLI  [-DecJare-j  ->  SS  d; 

AT  middle  1; 

[-STRUCT”],  ["Struct"!  [*KnownFrees"]  ->  SS  s; 

AT  middled, 

[-EXPfT],  ["Procedure"!  ["MACRO"]  -»  SS  e; 

AT  tail; 

END; 


EndRa  writes; 
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3-2  ProcessAttributeValueChanges(s) 

Comment 

This  rewrite  tailors  the  body  of  ProcessAttributeVaiue  (in  particular,  the  construct 
InitializeNameStackO)  to  properly  initialize  the  control  and  name  stacks.  Since  the 
initialization  of  these  stacks  is  done  by  the  FUI  tool,  none  need  be  done  by 
ProcessAttributeVaiue.  Note,  however,  that  the  variable  named  CurrentStatement  is 
initialized  to  be  the  construct  being  analyzed;  it  will  be  modified  as  we  go  along  to  keep 
track  of  the  then  current  statement  as  the  analysis  progresses. 

EndComment; 

Rewrites 

RAISE  D  InitializeNameStackO  (]  <-> 

RAISE  [)  DECL  CurrentStatementiFORM  LIKE  Value  (J 

EndRewrites; 


twww Statementlteration  t+++»++ 

4-1  Iterator(a) 

Comment 

In  addition  to  stepping  through  the  statements,  the  variable  named  CurrentStatement  is 
kept  up  to  date  and  the  counter  StatementCount  (for  the  current  control  stack  entry} 
incremented  as  well. 

EndComment; 

Rewrites 

(ForEachStatement  S$  s  in  It  f  REPEAT  ??  body  END)  <-> 

BEGIN 

DECL  f\:FORM  SYVAL  SS  f; 

REPEAT 

f\.CDR  -  NIL  ->  NOTHING; 
f\  <-  f\.COR; 

CurrentStatement  <-  f\.CAR; 

DEa  tt  s^ORM  SHARED  f\.CAR; 

T?  body; 

(It  sXop  e  'Declare''  -> 

ControlStack(CP].StatementCount  <- 
ControlStack[CP].StatementCount  ♦  1; 

END; 

END; 


EndRewrites; 
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PtOCBSSBEGIN  +' -*-M~ ♦  -M-M-M-M- -4-M-M-t-r+-M-++++ 

5-1  Enter  AndLaave(s) 

Comment 

Bock  entry  requires  making  an  appropriate  control  stack  entry  and  exit  requires  popping 
the  control  stack  after  resetting  the  name  stack  top  (NP).  Observe  that  we  insure  that 
there  is  a  position  on  the  controol  stack  for  the  "guard"  entry  required  by  the  name  stack 
lookup  mechanism  described  in  [2-7}. 

EndComment; 

Rewrites 

[)  Enter ESock(f);  ??  body;  LaaveBockO;  f  (]  <-> 

BEGIN 

(CP  <-  CP  +  1)  ♦  1  GT  LENGTH(ControiStack)  -> 

ExtendfControlStack); 

ControlStack£CP]  <- 

CONST(ControlStackEntry  OF  "Bock",  NP,  f); 

DECL  CurrentStatementrFORM  BYVAL  h 
T?  body; 

NP  <-  ControlStack[CP)r^>; 

CP  <-  CP  -  1; 
f; 

END; 


EndRewrites; 
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************ » *-» **********  Process  iterator  ******* 
6-1  EnterAndLeave(*) 

Comment 

Simitar  to  entering  and  leaving  a  block. 
EndComment; 

Rewrites 

D  EnterLoop(f);  TT  body;  LeaveLoopO  (J  <-> 

BEGIN 

(CP  <-  CP  1)  +  1  GT  LENGTKControlStack)  -> 
Extend(ControlSteck); 

ControtStack[CP]  <- 

CONST(ControlStackEntry  OF  loop',  NP,  f\ 
DECL  CurrentStatementiFORM  BYVAL  f; 

TT  body; 

NP  «-  ControlStack[CP]JYP; 

CP  «-  CP  -  1; 

END; 

End  Rewrites; 


ProcessCASE 


7-1  EnterAndleave(«) 


Rewrites 
BEGIN 
TT  head; 

EnterCASE(f); 

TT  middle; 
laaveCASEO; 
rt  tail; 

ETC  <-> 

BEGIN 
TT  head; 

(CP  <-  CP  f  1)  ♦  1  GT  LENGTKControlStack)  -> 
Extend(ControlStack); 

Control$tack[CP]  <- 

CONST(ControiSteckEntry  OF  •Case",  NP,  1>, 
DECL  CurrentStatementf  ORM  BYVAL  f; 

TT  middle; 

CP  <-  CP  -  1; 

TT  tail; 

END; 


End  Rewrites; 


Module  <AnalyzeI(  Application  is  Abstract)  d  61>  Scope<ProcessCASE) 


B  -  27 


7-2  Iterator(a) 

Rewrites 

(ForEachCASEArm  SS  a  in  SS  f  REPEAT  ft  body  END)  <-> 
BEGIN 

(St  aXResult  <->  (St  a).arg2; 

(ForEachControlQement  SS  a  in  (St  a). Control 
REPEAT  ??  inner \body  END)  <-> 

BEGIN 

(St  aXTests  <->  t\.CARj 
(St  aXPredicate  <->  t\.argl; 

OEa  t\fORU  BYVAL  (St  a).argl.args; 

REPEAT 

t\  -  nil  ->  NOTHING; 

71  innar\body; 
t\  <-  t\.CDR.CDR; 

END; 

END; 

DECL  g\rfrORM  BYVAL  (SS  O.COR.CDR.CDR; 

REPEAT 

g\  -  NIL  ->  NOTHING; 

CurrentStatement  <-  g\.CAR; 

DECL  SS  arFORM  SHARED  gVCAR; 

7?  body; 

ControlStack[CPJStatem#ntCount  <-  ~ 
CorrtrolStack[CP].StatementCourrt  +•  1; 
g\  <-  gVCDR; 

END; 

END; 


EndRewrites; 
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Pr  ocessEXPR 


8-1  Enter  AndLeave<*) 

Comment 

In  order  to  provide  context  for  the  client  tool,  we  here  provide  a  control  stack  entry  for 
both  the  0<PR  as  a  whole  (when  we  are  processing  the  formats  and  the  result  mode)  and 
for  the  body  itself. 

EndComment; 

Rewrites 

BEGIN 

EnterEXPRtfh 
ff  head; 

Enter  EXPRBody(f); 

7?  body; 

LeaveEXPRBodyO; 

LeeveEXPRO; 

f; 

END  <-> 

BEGIN 

(CP  <-  CP  +  1)  +  1  GT  L£NGTH(ControlStack)  -> 

ExtencKControiStack);  “ 

ControlStackfCP]  <- 

CONST(ControlStackEntry  OF  *EXPR",  NP,  f); 

DECL  CurrentStatementfORM  SYVAL  f; 

TT  head; 

(CP  <-  CP  +  1)  GT  LENGTH(ControlStack)  -> 

Extend(Control$tack); 

ControlStack[CP]  <- 

CONST(ControlStackEntry  OF  ’EXPRBody',  NP,  f.arg3fc 
CurrentStatement  <-  f  jrg3; 

??  body; 

NP  «-  ControlStack[CP  -  1 JJSIP; 

CP  <-  CP  -  2; 
f; 

END; 


EndRewrites; 
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^+^++^++*+++++»++++++-r++  SystemNames 
9-1  ProcessSystemProcedureApplication 
Comment 

This  procedure  is  called  when  f  —  g(al,  _,  an)  and  g  names  a  system  defined  procedure. 
If  g  is  a  quoting  operator  we  simply  return  f  and  if  g  is  not  a  rewrite  operator  we  process 
the  list  of  arguments  and  return  f. 

If  f  — ■  $S  x  or  f  —  ??  x,  we  procure  the  binding  of  the  match  variable  and  process  it. 

if  f  is  a  rewrite,  we  verify  that  we  are  not  currently  processing  an  interpretation  (rewrites 
not  being  permitted  within  analogies)  and,  if  not,  note  that  we  are  entering  a  rewrite  (via  a 
control  stack  entry),  process  the  pattern  to  introduce  the  match  variables  occurring  in  the 
pattern  into  the  environment,  and  then  call  ProeessExpression  on  the  replacement  (that  is, 
f.arg2).  CurrentStatement  is  also  set  to  be  the  rewrite  being  processed. 


EndComment; 

ProcessSystemProcedursApplication  <- 
EXPR(f:FORMj  FORM) 

CASE[f.op] 

["<"1  rOL’l  ["QUOTE"]  ->  f; 

[*«"]-> 

[)  Process  Expression(Match8indingFor(f));  f  (J- 
H?“]  -> 

BEGIN 

ForEachStatement  s 
in  CONS(NIL,  MatchBindingFor(f)) 

REPEAT  Process Expression(s)  END; 
f; 

END; 

[”<->1  ['<—>']  -> 

BEGIN 

Withinlnterpretation  ■> 

BEGIN 

ErrorToUserC 

A  rewrite  is  not  permitted  within  an  analogy;  it  is  being  ignored’); 
ML; 

END; 

EnterRewrite(f)j 
ProcessRewri  tePatternff  .arg  1 ); 

DECL  CurrentStatement:FORM  BYVAL  f; 
ProceeaExpression(f  jrg2h 
Leave  RewriteO; 
fl 

END; 

TRUE  ->  D  ProcessList(f  jrgsk  f  (1 
END; 
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Interpretations  +-t++>++»4- 

10-1  Scope 
Comment 

Recall  that  by  an  "interpretation"  we  mean  the  construct  that,  in  accordance  with  some 
analogy,  is  to  be  processed  in  liu  of  the  abstract  construct  that  actually  apopeared.  In 
order  to  determine  whether  a  given  construct  being  processed  is,  in  fact,  explained  by 
some  analogy,  we  employ  the  facilities  available  in  the  REWRITE  package  to  do  the  job.  If 
the  pattern  part  of  some  analogy  does  match  the  current  construct,  the  match  variables  of 
the  analogy  will  be  pushed  onto  the  name  stack  in  a  partition  associated  (via  the  control 
stack)  with  the  current  interpretation.  Detailed  comments  regarding  the  several  constructs 
involved  follow. 

EndComment; 


10-2  Interpretation 
Comment 

By  an  interpretation  we  mean  a  FORM  that  is  being  treated  specially;  thus  an  extende  mode 
based  on  FORM  is  employed. 

EndComment; 

Interpretation  <-  “Interpretations"  r.  FORM; 


10-3  Nulllnterpretation  <-  CONST(lnterpretation); 


10-4  FindlnterpretationFor 
Comment 

To  determine  whether  the  current  construct  ,  f,  has  an  interpretation  (that  is,  is  matched 
by  the  pattern  part  of  some  currently  active  analogy)  we  call  on  LookUpRewrite  (exported 
by  the  REWRITE  package)  giving  it  both  the  current  FORM,  f,  and  the  set  of  analogies 
currently  applicable.  It  is  here  assumed  that  the  client  tool  (FUt)  creates  and  manages  the 
set  of  analogies  currently  spoplicable  and  has  the  variable  named  CurrentAnalogies 
appropriately  bound.  If  the  match  is  not  successful,  tookUp Rewrites  returns  NOTHING  and, 
if  successful,  returns  the  replacement  part  of  the  analogy  matched.  FindlnterpretationFor 
then  either  returns  the  Nulllnterpretation  or  lifts  the  replacement  part  to  be  an 
Interpretation. 

EndComment; 

FindlnterpretationFor  <- 
EXP9(f:P0RM}  Interpretation) 

«  BEGIN 

DECL  lt0NE0F(N0NE,  FORM)  LIKE 
lookUpRewrite{f,  CurrentAnalogies); 

I  ■■  NOTHING  ■>  Nulllnterpretation; 

UFT(I,  Interpretation); 
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END; 


10-5  Interpret 
Comment 

A  control  stack  entry  is  made  to  record  the  fact  that  we  are  within  an  interpretation.  The 
match  variables  and  their  associated  bindings  are  returned  by  LookUpRewrite  as  a  list  (of 
DTPRs  named  GlobalBindUst)  whose  CARs  point  to  a  DTPR  whose  respective  CAR  and  COR 
are  the  match  variable  name  and  the  matching  construct.  These  are  pushed  onto  the  name 
stack  and  GlobalSindList  set  to  NIL  We  then  process  the  interpretation  (with  special 
consideration  for  the  Raised  block  construct).  Finally,  we  pop  the  control  and  name  stacks. 


EndComment; 

Interpret  <- 

EXPR<f:FORM,  ^Interpretation;  FORM) 

BEGIN 

(CP  <-  CP  ♦  1)  ♦  1  GT  L£NGTH(ControlStack)  -> 
Extend(ControlStack); 

ControlStack[CP]  <- 

CONST(ControlStackEntry  OF  "Interpretation*,  NP,  f); 
ForEachListElement  e  in  GlobalBindUst 
REPEAT  PushNameAndBinding(e.CAR,  e.COR)  END; 
GlobalBindList  <-  NIL; 

BEGiN 

IsRaisedBlock(T)  -> 

BEGIN 

T.argl.argl.op  *  "Analogies’  -> 
ProcessList(T.RaisedBlockContents); 

DECL  TemporaryAnaiogiesiAnalOgySet; 
AddToAnalogySet(Temporary  Analogies, 
T.argl.argl.args>, 

Push  Analogi  es(T  empo  r  ary  Analogies, 
CurrentAna/ogies); 

Process  List(T.arg  1  .args.args); 
PopAnalogies(CurrentAnalogies); 

END; 

T.op  e  “BEGIN*  OR  T.argl.op  •  "Analogies"  -» 
ProcessExpression(LOWER(T)>, 

OECL  Temporary  Analogies  Analogy  Set; 
AddToAnalogySet(TemporaryAnalogies,  T.argl.argsV, 
PushAnalogiesfTempor  ary  Analogies,  Cur  rent  Ana.ogies); 
ProcessList(T.args.args ); 
PopAnaiogies(CurrentAnalogies); 

END; 

VF  <-  ControiStackfCPlNP; 

CP  <-  CP  -  1; 
f; 

END; 

Rewrites 

Interpret  IS  f  as  IS  T  <->  Interprets,  T); 


Module  <AnalyzeI(  Application  is  Abstract)  @  61>  Scope  (Interpretations) 


B  -  32 


EndRewrites; 


10-6  R 

Rewrites 

lsRaisedB1ock($l  T)  <-> 

MCKVAUIS  T))  -  DTPR  AND  «t  T).CAR  -  “RAISE"; 

<11  TJ.RaisedBlockContents  <->  <11  T).CDR.CAR.CDR; 

Withinlnterpretation  <-> 

FOR  c  FROM  CP  BY  -  1 
REPEAT 

c  -  0  ->  FALSE; 

ControlStack[c].Type  -  “Interpretation"  ->  TRUE; 
END; 

EndRewrites; 


Process  Rewrite  -*•*  . . .  m  m  < 


1 1  - 1  Enter  AndLaave(*> 

Rewrites 
BEGIN 
7?  head; 

EhterRswrite(f); 

7?  body; 

LeaveRewriteO; 

7?  tail; 

END  <-> 

BEGIN 
7 1  head; 

(CP  <-  CP  +  1)  +  1  GT  LENGTVKCorrtrolStack)  -> 
Extend(ControlStack>, 

ControlStack(CP]  <- 

CONST<ControlStaekEntry  OF  “Rewrite*,  NP,  f); 

7?  body; 

NP  <-  ControlStack[CP}NP; 

CP  <-  CP  -  1; 

7?  tail; 

ENO; 

EndRewrites;  * 


11-2  ProcessRewritePattern  <- 
EXPR(lhs£0RM) 

BEGIN 

Ihs  -  NIL  ->  NOTHING; 
IsMetcHVariable(ihs)  -> 
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HaveRewrite8indingFor(lhs.argl)  ♦> 
PushN»rr»AndBinding(lhsjrgl>, 
MV(lhs)  •  DTPR  ->  NOTHINGS 
ForEachListElement  e  in  Ihs 
REPEAT  Process  RewritePattern(e)  END; 
END{ 


11-3  HaveRewriteBindingFor  <- 
EXPR<Name:FORMi  BOOL) 

«  BEGIN 

ControlStack[CP  +  1]  <- 
CONST(ControlStackEntry  OF  NIL,  NP>, 

FOR  c  FROM  CP  BY  -  1 
REPEAT 

c  •  0  “>  FALSE; 

ControlStack(c].Typa  -  "Rewrite*  -> 

FOR  np  FROM  ControlSt*ck[c  +  1JJ4P  BY  -  1 
TO  ControlStackfclNP  ♦  1 
REPEAT 

NemeStack£np].Name  -  Name  **> 
RETURNfTRUE); 

END; 

END; 

END; 


11-4  WithinRewrite 
Rewrites 

WithinRewrite  <-> 

FOR  c  FROM  CP  BY  -  1 
REPEAT 

c  -  0  ->  FALSE 

ControlStack[c)Type  -  "Rewrite"  ->  TRUE 
END; 

EndRewrites; 

WithinRewrite  <- 
MACRCXs  BOOL) 

FOR  c  FROM  CP  BY  -  1 
REPEAT 

c  «  0  ->  FALSE 

ControlStack[c].Type  -  "Rewrite"  *>  TRUE 
END; 


11-6  IsMatchVariable  <- 
MACRO(f:FORVA  BOOL) 

MD(VAL(f)>  -  DTPR  AND  (f.CAR  -  *tf"  OR  f.CAR  -  mmi 


Module  <AnalyzeI( Application  is  Abstract)  @  61>  Scope(ProcessMatcb Variables) 
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ProcessMatchVariables 


12-1  NonAtomicName  <- 
EXPR(Name:FORM) 

BEGIN 

MV(Name)  -  DTPR  AND  Name.op  -  *U*  -> 
BEGIN 

Withinlnterpretation  ■> 

Nama  <-  Match®  ndingFor(Name); 
WithinRewrite  ->  NOTHING- 
END: 

ErrorToUser(’ 

Tba  non-atomic  quantity  \  Nama, 

f 

appears  in  a  context  where  an  identifier  is  required.’}; 
END; 


12-2  MatchSndingFor  <- 
EXPW.-FORM;  FORM) 

FORM  « 

BEGIN 

CantrolStacK[CP  *■  1]  <- 
CONST(ControlStackEntry  OF  NIL,  NPh 
FOR  c  FROM  CP  BY  -  1 
REPEAT 

c  m  0  m>  [)  HaveUnknownAtom(f);  Nfl.  (J 
BEGIN 

ControlStack(cJ.Type  •  "Interpretation*  «> 
FOR  np  FROM  ControlStack[c  +  1]AP  BY  -  1 
TO  Control  Stack[c]JJP  ♦  1 
REPEAT 

NameStack[np]Alame  - f.argl  -> 
f  <-  NameStack[npJifindmg; 
lsMatchVariable<f)  •>  RETURNS); 

END; 

ControiStack[c)Type  -  "Rewrite"  •> 

FOR  np  FROM  Control Stackfc  +  l^NP  BY  -  1 
TO  ControlSteck[c)NP  ♦  1 
REPEAT 

NemeStack[nplNeme  -  fjirgl  -> 
RETLRNtNIU 
END; 

END; 

ENG 

END; 


Module  <AnalyzeI(Application  is  Concrete)  @  40> 
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1  Modulo 
Comment 


This  module  provides  a  refinement  to  Analyze  (plus  AnatyzeKGeneral))  that  is  appropriate 
for  analyzing  concrete  ELI  and  is  usable  by  the  Package  and  Synonym  tools.  No  record  of 
the  current  context  will  be  kept  (other,  of  couse,  than  the  stack  of  names  local  currently 
local)  but  we  will  permit  the  analyzer  to  be  called  recursively  (as  is  necessary  for  the 
Package  tool).  This  is  accomplished  by  mechanisms  that  protect  the  local  name 
environment  of  one  call  from  subsequent  recursive  calls  on  ProcessAttributeValue.  Further 
commentary  is  provided  with  the  various  constructs  being  defined. 

EndCommenh, 

Module  has  Uses(Analyze,  ListUtilities); 


NameStack 

2-1  NameStackEntry  <-  STRUCT(Name:FORM)j 


2-2  Iterator(a) 

Comment 

To  accomodate  recursive  calls  on  the  analyzer,  a  variable  named  NPBottom  will  be 
introduced  to  hold  on  to  the  current  ‘bottom'*  of  the  NameStack.  The  iteration  over  the 
"relevant"  NameStack  entries  is  therefore  over  those  indexed  by  NPBottom,  NPBottom  +  1, 
-» NP. 

EndComment; 

Rewrites 

(ForEachRelevantNameStackEntry  If  j  REPEAT  V.  body  END)  <-> 

FOR  j  FROM  NP  BY  -  1  TO  NPBottom  REPEAT  ??  body  END; 

EndRewrites; 


2-3  NonAtomicName  <- 
MACRCXatonuFORM) 

ErrorTollserC 

The  non-stomic  quantity  \  atom, 

* 

appears  in  a  concrete  context  where  an  identifier  is  required.*); 


Module  <AnalyzeI(Application  is  Concrete)  &  40>  Scope  (BasicProcessing) 


BasicProcessing 


3-1  Process  ExpressionChanges(») 


Rewrites 
BEGIN 
Tf  heed; 

□ECL  Interpretation  LIKE  FindlnterpretationFor(f); 
T  e  Nulllnterpretation  ->  Interpret  f  as  T; 

7?  tail; 

END  <->  [)  ??  head;  ??  tail  (J 
EndRewrites; 


3-2  ProcessAttributeValueChanges!*) 

Rewrites 

[)  7!  head;  InitializeNameStacKO;  ??  tail  (]  <-> 
BEGIN 
??  head; 

DECL  NPBottomrlNT  BYVAL  NP  *  1; 
rr  tail; 

NP  <-  NPBottom  -  1; 

END; 

EndRewrites; 


+++  «■♦■*•+ 


Statementtteration 


4-1  Iterator!*) 


Rewrites 

(ForEachStatement  It  s  in  SI  f  REPEAT  7!  body  END)  <-> 
BEGIN 

DECL  f\:FORM  BYVAL  It  f; 

REPEAT 

f\.CDR  -  NIL  ->  NOTHING; 
f\  <-  f\.COR; 

DEa  It  s:FORM  SHARED  f\.CAR; 
ft  body; 

ETC; 

END; 


EndRewrites; 
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»♦+++++++»  *+++♦■«-»+++»++++•»+  ProcessBEGIN  -*-h 

5-1  Enter  AndLeavel*) 

Rewrites 

D  EnterBlocklf);  77  body;  LeaveBlockO;  f  (]  <-> 
BEGIN 

DEO.  SevedNPdNT  BYVAL  NPJ 
??  body; 

NP  <-  SavedNP; 
fs 

END; 

EndRewrites; 


Processlterator 


6-1  Enter  AndLesve(*) 


Rewrites 

D  EnterLooptf);  ??  body;  LeaveLoopO  (]  <-> 

D  OECL  SavedNPdNT  BYVAL  NP;  77  body; TIP  <-  SavedNP  (J 

EndRewrites; 


ProcessCASE 


7-1  EnterAndLeavet*) 

Rewrites 
BEGIN 
77  heed; 

EnterCASE(f); 

??  middle; 

LeaveCASEO; 

77  tail; 

END  <->  [)  77  head;  ??  middle;  77  tail  (J 


EndRewrites; 


Module  <AnalyzeI(Application  is  Concrete)  @  40> 


7-2  Iterator(a) 

Rewrites 

(ForEachCASEArm  tS  a  in  $S  f  REPEAT  ??  body  END)  <-> 
BEGIN 

(It  ajitosult  <->  (It  aLarg2; 

(ForEachControlDement  St  e  in  (M  a).Control 
REPEAT  ??  inner\body  ENO)  <-> 

BEGIN 

(IS  e).Tests  <->  t\.CAR; 

(IS  eLPredicate  <->  tVargl; 

DECL  t\:FORM  BYVAL  (SI  a).argl.args; 

REPEAT 

t\  -  ML  ->  NOTHNG; 

Tt  inner\bodyi 
t\  <-  tVCOR-CDR; 

END; 

ENOfc 

DECL  g\:FORM  BYVAL  (SI  f).CDR.CDR.CDR; 

REPEAT 

g\  ■  ML  «*>  NOTHING; 

DECL  H  rfORM  SHARED  g\.CAR; 

V  body; 
g\  <-  gVCOR; 

END; 

END; 


Scope(ProcessCASH)  B  •  38 


EhdRewrites; 
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ProcessEXPR 


S-l  EnterAndLeave<*) 

Rewrites 

BEGIN 

EnterEXPRff); 

71  head; 

EnterEXPRBody<f); 

??  body; 

LeaveEXPRBodyO; 

LeaveEXPRO; 

f; 

END  <-> 

BEGIN 

DECL  Saved  NP:INT  BYVAL  NPj 
T?  head; 

??  body; 

NP  <-  Saved NP-, 

f; 

END; 

EndRewrites; 


mu »»»+-*-»»♦+♦-»»++♦  m »+»*♦»  SyrtemNames 

9-1  ProeessSystemProcedureApplicstion  <- 
EXPRtfrFORMj  FORM) 

CA$E[f.op] 

[-<-1  [*QL"i  [-QUOTE-]  ->  h 

nn  nn  r<^*i  t*<— >t  -> 

[)  NonConcreteConstruct(f);  f  (J 
TRUE  ->  [)  Proce«sUst(f  jrgsh  f  (J 
END; 


9-2  NonConcreteCorstruct  <- 
MACRCXfsFORM;  FORM) 

ErrorToUser^ 

The  following  non-concrete  construct  is  being  ignored: 
f>5 


Module  <AoalyzeI( General)  %  34> 
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1  Module 
Comment 


This  module  provide*  a  collection  of  refinements  for  various  of  the  abstract  constructs 
employed  in  Analyze.  By  general,  here,  we  mean  refinements  that  will  be  appropriate 
independent  of  the  particular  application  for  which  we  are  refining  the  model.  For  the 
most  pert  these  refinements  have  to  do  with  defining  the  abstract  iterators  and  selectors 
in  terms  of  the  concrete  internal  representation  of  ELI.  in  addition,  there  are  refinements 
fo  dealing  with  system  names;  these  are  commented  upon  when  they  are  defined. 

EndComment; 

Module  has  Uses(Analyze,  UstUtilitiesh 


BasicProcessing 


2-1  IsConstant(s)  <- 

MACRCKfjFQRkk  BOOL) 

BEGIN 

f  -  NIL  ->  TRUE; 

DECL  M-JvOOE  LIKE  M0(VAL{f)H 
M  -  NT  OR  M  -  REAL  OR  M  -  REF  OR  M  -  DDB; 
END; 


2-2  Isldentifier(s)  <-  MACR0(f:F0RU  BOOL)  MD(VAL(f))  -  ATOM; 


♦  »+♦♦++  +.  »»♦■»+■»+♦  ProcessModeAndComponentsSpecified 

3-1  Process  Mo  deAndSpecFor(«)  <- 
MACRCXd-JORM) 

BEGUN 

/*  ’  d  mm  (vars  md  BC  si  -  sn)’j 
ProcessExpressiorKd.COR.CAR>, 
dCORCOR  •  NIL  ->  ProcessList(cLCDR.CDR.CDRh 
END; 
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Processlterator 


4-1  Iterator!*) 

Rewrites 

(ForEachlteratorElement  ft  e  in  II  f  REPEAT  ??  body  END)  <-> 
BEGIN 

IsBodydt  e)  <->  (H  #).CAR  -  “REPEAT; 
talteratorVariableSpecdf  e)  <->  (II  aXCAR  ■  “FOR*; 

(It  eXlteratorVeriabie  <->  (H  »).trgl; 

(I I  eXSpec  <->  (It  eXergl; 

DECL  It  esfORM  BYVAL  (It  f).COR; 

It  e  -  ML  -»  NOTMNGi 
REPEAT 
??  body; 

(It  e).CAR  -  “REPEAT*  •>  NOTHNG; 

It  e  <-  (It  o).CDRCDR-, 

END; 

END; 

End  Rewrites; 


ProcessDECL 


5-1  Iterator 


Rewrites 

(ForEachDECLEIement  If  d  in  It  f  REPEAT  7f  body  END)  <-> 
BEGIN 

(ForEachLocalName  ft  n  in  ft  d 
REPEAT  7?  inner \body  END)  <-> 

BEGIN 

DECL  n\fORM  BYVAL  (II  d).CAR; 

REPEAT 

n\  -  ML  ->  NOTHING; 

DECL  It  nsFORVI  SHARED  n\.CAR; 
n\  <-  nVCDR; 

Tf  inner\body; 

END; 

END; 

DEa  f\:FORM  BYVAL  (II  O.CDR; 

REPEAT 

f\  -  ML  ->  NOTHING; 

DEa  It  d^ORM  LIKE  f\.CAR; 

?!  body; 
f\  <-  fVCOR; 

END; 

END; 


EndRewrites; 
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Process  STRUCT 


6-1  Iterator^) 

Rewrites 

(ForEachSTRUCTMode  «|  m  in  f|  S  REPEAT  V.  body  END)  <-> 
BEGIN 

OECL  m\^ORM  BYVAL  MS  SXCOR; 

REPEAT 

m\  -  ML  ->  NOTHING; 

DEa  SS  miFORM  SHARED  m\.CAR.argl; 
ft  body; 
m\  <-  m\.CDR; 

END; 

END; 


End  Re  writes; 


Pr  ocessCASE 


7-1  General(«) 

Rewrites 

MS  fXCASEReiations  <->  MS  fXargl; 
(SS  fXCASEArguments  <->  (SS  fXarg2; 
End  Rewrites; 


♦-*-»  »■»»»»  »  ProcessDoubleColon  -m-h 

8-1  SpecifiesUserBetiavior  <- 
MACRCXf^ORM;  BOOL) 

MV(f)  -  DTPS  ANO  (f.CAR  -  '<“  OR  f.CAR  -  “QL*); 
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ProcassPROC 


9-1  Iterator 


Rewrites 

(ForEachFormaiMode  SI  m  in  14  f  REPEAT  ??  body  END)  <-> 
BEGIN 

DECL  q:FORM  BYVAL  (II  O.CDR.CAR; 

REPEAT 

q  -  NIL  ->  NOTHING; 

DECL  II  m:FORM  SHARED  q.CAR.CAR; 

??  body; 
q  <-  q.CDR; 

END; 

END; 


EndRewrites; 


ProcessEXPR 


»4  M-4444-4-44444-4  »44-4"44-4-44-4-4-4- 


10-1  Iterator 
Rewrites 

(II  fLResuitMode  <->  (II  f).arg2; 

(44  f).Body  <->  (99  f).arg3; 

(ForEaehFormel  II  d  in  It  f  REPEAT  7?  body  END)  <-> 
BEGIN 

(H  d).Name  <->  (II  d).CAR; 

DECL  h\:FORM  BYVAL  (II  f).argl; 

REPEAT 

h\  -  NIL  ->  NOTHING; 

DECL  II  d.-FORM  SHARED  h\.CAR; 

7?  body; 
h\  <-  hVCOR; 

END; 

END; 

EndRewrites; 


SystemNames 


11-1  Scope 
Comment 

This  scope  provides  an  implementation  of  the  handling  of  system  names  via  a  hash  table. 


EndComment; 


Module  <AualyzeI(General)  %  34>  Scope(SyrtetnNames) 


11-2  IsSystemProcedure  <- 

MACRCXptPORM;  BOOL)  FINDHASKSystemNames,  p,  TRUE); 


11-3  SystamNames 

SyatamNamas  <-  CONST(HASHTABLE>, 
Initialization 

InitializaSystemNamesO; 


Endlnitiaiization; 


Module  <AnalyzeI(General)  @  34>  Scope(SystemNames) 


11-4  InitializeSystemNames  <- 
EXPR() 

BEGIN 

SystefnNarr.es  <-  MAKEHA$H(FORM,  BOOL,  150,  80); 

OECL  UFORM  LIKE 

UST (“<“,  “QL“,  “QUOTE",  “tt“,  TT,  *<->*, 

*< - >*,  V,  *->*,  “♦>*, 

*•>*,  f,  "FOR",  TINDHASH*,  “MAKEHASH“, 
“VEMBHASH",  “FLUSHASH",  'REHASH*,  “SIZE*, 
*MO*.  *VAL“,  *+*,  'SUM*,  '-*,  "DIFF",  '*“, 
“PROOUCT", */*,  “QUOTIENT,  *-*,  “EQUAL*,  '«', 
“NEQUAL",  'AND',  'OR*,  “NOT,  “RETURN*,  'GE', 
*GT,  “L£“,  *LT,  “CAR*,  *CDR“,  “PRINT*, 

“PFORM*.  “READ*,  “MAKEPF*,  “INCHAR*, 
“OUTCHAR*,  1N0BJ",  “OUTOBJ*,  *BASIC\STR*, 
“LEX*,  “PARSE",  INFIX*,  “PREFIX*,  “NOFIX", 
“FLUSHF1X*,  “RETURN",  "HASH*,  "LENGTH*, 
“COVERS',  *CHA R\INT,  *1  NT\CHARm,  -LIFT, 
TOWER*,  "STINT,  ’STREAL*,  *REAL\STR“, 
“DRAIN",  *PORT\STR",  “OPEN*,  "CLOSE*,  TOAD", 
TOADB*.  “ASSERT,  “RECLAIM*,  *RTIME“, 
“GCTIME",  "SAVE",  “RESTORE",  “COMPLETE", 
“TECO*,  “MAKE",  "BREAK*,  “CSREC",  "NSREC“, 
“PEEK",  “POKE*,  “FLUSH",  TOCATE",  “RESET, 
“CONT,  “STACKS",  "STEP",  “RETBRK", 
“CONSTRUCT*,  “DIMENSIONS*,  "STRUCT,  “PTR“, 
“ONEOF*.  "PROC“,  “SEQ“,  “VECTOR",  “SELECT, 
“RENAME*,  “SETBYTE*,  *MATCHFIX“,  “PACKOBJ*. 
“REVIVEPORT",  “CONS',  "MAKEFORM*,  TJSTCOPT, 
TlSTEQUAL",  “UST APPEND",  T1ST*, 

T1STSUBST,  “SYNFIX",  “CIPORT,  “COPORT*, 
*PIPORT“,  ”POPORr>, 

REPEAT 

L  -  NIL  ->  NOTHING; 

FlNDHA$H(SystemNames,  LCAR)  <-  TRUE; 

L  <-  LCDR; 

END; 

END; 
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Appendix  C 


FUI:  Find  Undefined  Identifiers 


<  FUi  a  54  > 


1  Module 

Module  has  llses(ANLZA[21  Utilities,  Listlltilities); 
Module  has 

ExportedSyntaxtEquatePhrasesOSI  x  Isir  U  S’, 

’Six  ♦  SIS’))! 

Analogies 

It  x  isin  IS  S  <}>  D  *•  X5  S*  S  (J 
EndAnalogies; 


m-*  InterfaceToAnalyze" 

2-1  Analyze  <- 

EXPR(CurrentEntityNanne£ntityName, 

ValuesFORM, 

Globals:Set(EntityNsme), 

FreesList.-FQRM  SHARED, 

CalleesList£ORM  SHARED) 

BEGIN 

(CP  <-  CP  +  1)  GT  LENGTKControlStacK)  -> 
Extend(ControlStack); 

ControlStack[CP]  <- 

CONST(ControlStackEntry  OF  ML,  NP,  Value); 
ProcessAttributeValue(Value,  Analyze  HaveUnknownAtom, 

Analyze  ProcessUserProcedureApplicat  ion, 

AnalyzeProcessBehaviorFunctions, 

AnalyzeErrorToUser); 

NP  <-  ControlStacK[CP].NP; 

CP  <-  CP  -  1; 

END; 


2-2  Analyze  HaveUnknownAtom 

AnalyzeHaveUnknownAtom  <- 
EXPR(atom£ORM;  FORM) 

BEGIN 

atom  Isin  Globals  ->  atom; 
MakeFreeVariableEntryFor(FreesList,  atom); 
atom; 

END; 
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AnaiyzeHaveUnknownAtom  has 
KnownFraas(Globals:Sat(EntityName),  FraesListtFORM); 


2-3  AnalyzeProcessUserProcedureApplication 

AralyzeProcessUserProcedureApplication  <- 
EXPWiFORM;  FORM) 

BEGIN 

DECL  op^ORM  LIKE  f.op; 
AnalyzeHaveUnknownAtom(op); 

Append  op  To  CailaesList; 

ProcassList(Largs); 

f; 

END; 

AnalyzaProcassUsarProcaduraApplication  has 
KnownFrees(CallaesList:FORM); 


2-4  AnalyzaProcassBehaviorFunctions 

AnalyzeProeessBehaviorFunctions  <- 
EXPR(f:FORM) 

BEGIN 

/*'  f  —  <  ShortName,  UFl(nl),  _> ’; 

DECL  ShortNameiFORM  LIKE  f.argl; 
ForEachListArgument  a  in  fairgs 
REPEAT 

DECL  oprFORM  LIKE  axip; 
VatidBehaviorFunction(op)  +> 
NotaUnknownBahaviorFunctiontFraasList, 
ShortName,  op); 
DECL  atom;FORM  LIKE  a.argl; 

BEGIN 

Isldentifier(atom)  ■> 
AnalyzaHavaUnknownAtom<atom>, 
IsConstant(atom)  ->  NOTHING; 

ErrorO; 

END; 

END; 

END; 

AnalyzeProcessBehaviorFunctions  has 
KnownFraas<FraasListfORM); 


2-5  ValidBahaviorFunctlon 

ValidBahaviorFunction  isa  ProcedurMopf  ORM;  BOOL)  - 
Returns  TRUE  iff  op  names  a  behavior  function. 
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C-2 


2-6  AnalyzeErrorToUser 

AnalyzeErrorToUser  <- 
EXPR(Laft STRING,  frFORM,  Right  :STRiNG) 

D  PRINT<Left);  UNPARSFUifh  PRINT(Right)  (J 

AnalyzaErrorToUsar  has  KnownFrees(llNPARSFM:ROUTINE); 


2-7  MakeFreeVariableEntryFor 
Comment 

MakeFreeVariabieEntryForfFreesUst,  atom)  constructs  and  adds  to  FraasList  an  entry 
indicating  that  the  identifier  named  atom  occurs  free  in  the  construct  currently  being 
analyzed.  It  does  this  by  tracing  back  the  control  stack  entries  to  construct  a  "template* 
for  the  current  construct  that  indicates  where  in  the  construct  atom  occurs  free.  The 
variable  named  CurentStatement  is  asumed  bound  to  the  particular  statement  currently 
being  analyzed  (tyhe  control  stack  not  having  granularity  finer  than  a  block,  loop,  or  case. 

EndComment; 

MakeFreeVariableEntryFor  <- 
EXPRfFreesUstfORM  SHARED,  atom:F0RM> 

«  BEGIN 

ForEachListArgument  a  in  FreesList 
REPEAT 

ajrgl  -  atom  «•> 

BEGIN 

a^argl  <-  LIST(atom,  2)s 
*~arg2  <-  Abbreviate<a.arg2)i 
RETURN); 

END; 

ajrglUJp  •  atom  -> 

BEGIN 

ajrgl.argl  <-  UST(VAL(a.argl.argl)  +  1Y, 

RETURN); 

END; 

END; 

DECL  Resuit^ORM  UKE  UST("within",  atom,  MU 
DECL  FilifORM  BYVAL  Result.args; 

«  BEGIN 

FOR  c  TO  CP 
REPEAT 

CASE[ControlStack[c].Type] 

HBIock"]  -> 

BEGIN 

DECL  R^ORM  BYVAL  ControlStack[cJ.f; 
c  GT  1  AND 

ControlStacktc  -  lJType  - 
Interpretation"  -> 

R  <-  ControiStack[c  -  ljf; 

DEa  CountdNT  UKE 
Control$tack[cJ.StatementCount; 

FilLargl  <- 
BEGIN 


J 


Module  <FUI  @  54>  Scope(InterfaceTo Analyze) 


Count  *  0  -> 

USKRop, 

USTC-*, 

ALLOCdNT  LIKE 
Count)),  NIL); 

USKFLop,  NIL); 

ENO; 

FOR  j  FROM  c  -  1  BY  -  1 
REPEAT 

j  -  0  ->  NOTHING; 

DECL  t  SYMBOL  LIKE 
ControlStackftJType; 

t  -  "Cose"  <■> 

BEGIN 

DECL  ptFORM  BYVAL 
ControlStack[j].f.args.args.args; 
TO  ControlStack[j].StatementCount 
REPEAT  p  <-  p-args  END; 

FilLargl  <- 
LJST{*->",  p-op.argl, 

Filljrgl); 

Fill  <-  Fill.argl.args; 

END; 

t  •  Interpretation*  «*>  NOTHING; 

END; 

Fill  <- 
BEGIN 

Count  •  0  **>  Fill.argl.args; 

FilLargl; 

END; 

EM); 

["Case"]  ■> 

BEGIN 

DECL  RfORM  BYVAL  ControlStacK[c].f; 
c  GT  1  AND 

ControlStack[c  -  l].Type  - 
"Interpretation*  -> 

R  <-  ControlStackfc  -  l  if; 

DEa  CountdNT  UKE 
ControlStack[c].StatementCount; 

BEGIN 

Count  »  0  -> 

BEGIN 
FilLargl  <- 
USTCCASE",  ML,  MU 
UST(*->“, 

USTOT.  NIU 

ML), 

USTC-",  Count)), 

CQNSOk 
Fill  <- 

FilLarg  l-args.arg5.frgs; 

END; 

FilLargl  <- 

UST(*CASr,  MU  MU  CONSO); 

Fill  <-  FilLargl.args.argc; 
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END; 

END; 

["Loop*]  •> 

BEGIN 

DECL  RsFORM  BYVAL  ControlStack[c].f; 
cGT  1  AND 

ControlStack[c  -  l].Type  - 
"Interpretation"  -> 

R  <-  ControlStack[c  -  ljf; 

DEa  Filler ;FORM  LIKE 
UST(R.CAR,  R.CDR.CARV, 

DEa  LF-FORM  BYVAL  FMer.CDR; 

R  <-  Rergsj 
REPEAT 

MV(R-CAR)  -  ATOM  AND 
R.CAR.SBLK  *  NIL  APC 
R.CAR.S8LK.SINF0  - 
"REPEAT" .SBLK.SINFO  -> 

NOTHING; 

R  <-  R.CDR; 

LF  <-  LF.COR  <-  CONS(R-CAR); 

END; 

DECL  Count-JNT  UKE 
CantrolStack[c].StatamentCount; 

LF.COR  <- 
BEGIN 

Count  •  0  -> 

UST{UST("_", 

AlLOCONT  LIKE 
Count)),  NIL); 

U3T(NIU; 

END; 

FOR  j  FROM  c  -  1  BY  -  1 
REPEAT 

j  -  0  ->  NOTHING; 

DEa  tiSYMBOL  UKE 
ControlStackQJTy  pe; 

t  -  "Case"  -> 

BEGIN 

DEa  ptFORM  BYVAl 
ControlStackOJf-args^rgsjrgs; 
TO  ControlStack[jiStatementCount 
REPEAT  p  <-  p.args  END; 

Filler  <- 

UST("->",  p.op.argl, 

Filler); 

END; 

t  e  "Interpretation"  ■»  NOTHING; 

END; 

FilLergl  <-  Filler; 

Fill  <- 

[)  Count  -  0  ->  LF;  LF.COR  (J 
END; 

["EXPRBody"]  -> 

BEGIN 
FilUrgl  <- 
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USKTXPR",  ML,  NONE,  NIL); 

Fill  <-  Fill.argl.CDR.CDR; 

END; 

[*EXPR*]  c  -  CP  -> 

BEGIN 
FtlLargl  <- 

USTAPPEND(Control$tack[c].f); 

Fill.argl.arg3  <- 
RETURNO; 

END; 

ENO; 

END; 

CurrentStatement  #  ML  -> 

FilLargl  <- 
BEGIN 

NOT  IsMatchVariabie^t-rentStatement)  -> 
Abbreviate(CurrentStatement); 

DECL  ErrorToUsertPROaSTRING, 

FORM, 

STRING)  LIKE 
AnalyzaErrorToUsar; 

Abbraviate<MatchBindingFor{CurrentStatament)h 

END; 

END; 

Append  Result  To  FreesList; 

END; 

MakeFreeVariableEntryFor  has 
KnownFrees(CurrentStatement:FCRM); 


2-8  Abbreviate  <- 

EXPR(f:FORM;  FORM) 

BEGIN 

OECL  apfORM  LIKE  f.op; 

MV(op)  •  ATOM  ->  f; 

DECL  SINFO--ANY  UKE 
[)  op.SBLK  -  ML  ->  0;  op^BLK-SINFO  (} 
CASE[SINFO] 

[”BEQN".S8LK.S1NF0]  -> 

BEGIN 

f.args  -  NIL  ->  UST(op); 

UST{op,  Abbreviated. argl),  "_’); 

END; 

[■REPEAT*.SBLiCSINF01  [TOR’.SBLK.SINFO]  -> 
BEGIN 

DEa  LFORM  UKE  CONS(op); 

OEa  pfORM  BYVAL  Lf 
OECL  qfORM  BYVAL  f.CDR; 

REPEAT 

p  <-  p.CDR  <-  CONS(Abbreviate(q.CAR)); 
MV(p.CAR)  -  ATOM  AND  Q.CAR.SBLK  a  ML  AND 
P-CAR.S8LK.SINF0  -  •REPEAT.SBLK.SINFO  -> 
BEGIN 

q.arg*  a  ML  -> 

p  <-  UST(Abbreviata{q.srgl),  ■_"); 
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L: 

END; 

q  <-  q.COR; 

ENDS 

END; 

[’•CASE’.SBUCSINFO]  -> 

BEGIN 

DEa  LFORM  BYVAL 
UST(op,  Abbreviatelf.argl), 
Abbreviate(f.arg2)); 
f-args.args.args  -  NIL  ->  U 
Largs.args.args  <- 
UST<Abbreviate(f.arg3), 

Li 

END; 

[”EXPR“.SBLK.SINFO]  -> 
USTCEXPR",  NIL,  NONE, 

TRUE  ->  f; 

END; 

END; 


2-9  NoteUnknownBehaviorFunction  <- 

EXPR<FreesList:FORM  SHARED,  ShortName:FORM,  opfORM) 
Append  LlSTCin",  USTCBehaviorFunction^ op), 
ShortName)  To  FreesList; 


2-10  DoAnalysisOf 
DoAnalysisOf  <- 

EXPR(E£ntity,  Attribute,  Qobals:Set(EntityName)) 
BEGIN 

DECL  FreesListsFORM  BYVAL  LISTCBEGJN*); 

DECL  CalleesList:FORM  BYVAL  USTCBEGHVT); 
Analyze<EJ^ame,  AttributaValueOf(A),  Globals, 
FreesList,  CalleesList); 

NewFreeVariablesAttributeFoKE,  A,  FreesList); 
SaveProceduresCalledAttribute  -> 
NewProceduresCalledAttributeFor(E,  A,  CalleesList); 
END; 

DoAnalysisOf  has 

KnownFrees(SaveProceduresCalledAttribute:BOOL); 


■r-M-a »++++♦+♦•»■++ +++■»♦  »  FindUndefinedldentifiers 
3-1  Scope 
Scope  has 

ExportedSyntax(EquatePhrases(TorEachEntity  It  E  in  It  M\ 
’FOR  It  E  FROM  It  M*), 
EquatePhrases(TorEachScope  It  S  ForModule  It  M*, 


I 
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*  FOR  SIS  FROM  ISM*), 

EquatePhrasesCForEachEntity  SS  E  WithinScope  St  S’, 

*  FOR  SS  E  FROM  SI  S’), 

EquatePhrasesCForEachAttribute  SS  A  of  SS  F, 

*  FOR  IS  A  FROM  SS  F), 
EquataPhrases(’Add  SS  a  ToSat  SS  S', 

Sla  +  US')); 

Analogies 

(ForEachEntity  SS  E  in  SS  M  REPEAT  7t  body  END)  <}> 

REPEAT  Declare  SS  EANY  UKE  SS  Mi  ??  body  END; 

(ForEachScope  SS  S  ForModule  SS  M  REPEAT  7!  body  END)  <}> 
REPEAT  Declare  SS  S:ANY  UKE  SS  M;  7t  body  Em 

(ForEachEntity  SS  E  WithinScope  SS  S  REPEAT  V.  body  END)  <}> 
REPEAT  Declare  SS  E-.ANY  LIKE  SS  Si  ??  body  END; 

(ForEachAttribute  SS  A  of  SS  E  REPEAT  7*  body  END)  <}> 

REPEAT  Declare  SS  AsANY  LIKE  SS  E;  ??  body  END; 

Add  SS  e  ToSet  SS  S  <}>  IS  e  +  SS  S; 

EndAnalogies; 


3-2  FindUndefinedldentifiers 

FindUndefinedldentifiers  <- 
EXPR(Result:Mcdule, 

Parents:SEQ(  Module), 

OdResult:Module, 

CTdParentDescnptors:SEQ(ModuleOescriptor), 

ReDoAllsBOOL; 

Module) 

BEGIN 

LoadAppropriatePacKagesO, 

NP  <-  0; 

CP  <-  0; 

AnnounceTool(FindUndefinedldentifiers,  Result); 

OECL  GtobalAnalogiesiAnalogySet; 

DECL  Current  Analogies  An  alogyEnvironment; 

DECL  SaveProceduresCalledAttribute:800L  UKE 
SaveProceduresCalledAttributeFor(Resutt); 

DECL  SVfcSyntaxMark  UKE  MarkSyntaxO; 

DECL  Globals:Set(EntityNameh 
FOR  j  FROM  2  TO  LENGTVKParents) 

REPEAT 

DECL  Mddoduie  UKE  Parents[j]i 

Fetch£ntitiesAndAttributesFor(M>; 

NewSyntax(M.ExportedSyntax); 

SetupToDetectChangesSince(OldParentDescriptors[j]); 
ForEachEntity  E  in  M 
REPEAT 

AddToAnalogiesAndQobalsfE, 

TRUE  IE 


i 


I 

I 


i 
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’a  used  module’, 

ReDoAII,  Globals, 
GlobalAnalogies); 

END; 

Close  Mcdule(M); 

END; 

DECL  Basis:Modula  LIKE  -arents[li 
FetchEntitiesAndAttributesFor(Basis)j 
NewSyntax(Basis£xportedSyntax); 
NewSyntax(BasislocalSyntax); 

SetupToDetectChangesSincs(OldParentDescnptors[l]>, 
ForEachEntity  E  in  Basis 
REPEAT 

AddToAnalogiesAndGlobals(E, 

FALSE  IE 

the  basis  module’, 

ReOoAll,  Globals, 
GlobalAnalogies}; 

END; 

PushAnalogies(QobalAnalogies,  Current  Analogies); 
lnitiaiizeResultModule<  Result); 

ForEachScope  S  ForModule  Basis 
REPEAT 


InitializePerScope(S); 

DECL  ReDoScope :BOOL  BYVAL  ReDoAM; 

DECL  ScopeAnalogies:AnalogySet; 

ForEachEntity  E  WithinScope  S 
REPEAT 

AddScopeLocalAnalOgiesAndNamestE,  ReDoScope, 
Scope  Analogies); 

END; 

PushAnalogiestScopeAnalogies,  CurrentAnalogies); 
ForEachEntity  E  WithinScope  S 
REPEAT 

DECL  KFA,  BA,  TA,  QA,  RA:Attribute; 
ForEachAttribute  A  of  £ 

REPEAT 

NOT  AXtoleted  -> 

CASE[A.Type] 

[BindingAttributeT  ype  1 
[MacroAttributeType]  ->  BA  <-  A; 
[KnownFreesAttributeType]  ■>  KFA  <-  A; 
[RewritesAttributeType]  ■»  RA  <-  A; 
[TypeAttributeType]  ->  TA  <-  A; 
[DescriptorAttributeType]  ->  DA  <-  A; 
END; 

END; 

DECL  Changes :900L  UKE 
ReDoScope  OR  IsChanged(BA)  OR 
lsChanged(KFA)  OR  IsChanged(RA)  OR 
BA  -  NullAttribute  AND 
(IsChangedfTA)  OR 

TA  -  NullAttribute  AND  IsChangecKDA)); 

BEGIN 


NOT  Changes  ->  NOTHING; 
InstallKnownFrees(KFA); 
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BEGIN 

BA  •  NullAttribute  -> 

DoAnalysisOfiE,  BA,  Globais); 

TA  •  NullAttribute  -> 

DoAnalysisOf(E,  TA,  Globais); 

DA  •  NullAttribute  -> 

DoAnalysisOf(E,  DA,  Globais); 

RA  •  NullAttribute  -> 

DoAnalysisOf(E,  RA,  Globais); 

KFA  •  NullAttribute  -» 

DoAnalysisOf(E,  KFA,  Globais); 

END; 

RemoveKnow  nF  rees(>, 

END; 

END; 

PopAnalogies(CurrentAnalogies); 

RemoveScopeDependentAnalogiesAndNamesO; 

END; 

PopAnalogies(CurrentAnalogies); 

CloseModule(Basis); 

InstallNewModule(Result); 

RestoreSyntax(SM); 

Result; 

END; 

FindUndefinedldentifiers  has 
KnawnFrees(SeveProceduresCai)edAttribute:BOOL); 


3-3  AddToAnalogiesAndGlobals  <- 
EXPR(E£ntity, 

lsBasisModuie:800L, 

ReOoAlhBOOL  SHARED, 

Gtabals:Se t<Enti ty Name )  SHARED, 
GlobalAnalogies:AnalogySet  SHARED) 

BEGIN 

DEa  KnowniBOOL  BYVAL  TRUE; 

DECL  Has  Binding  SOOL  BYVAL  FALSE; 

DECL  AA^ttribute; 

DECL  ChangedAnalogyrBOOL  BYVAL  FALSE; 

DECL  ChangadBinding:900L; 

ForEachAttribute  A  of  E 
REPEAT 
CA$E[A.Type] 

[KndingAttributeTypel 
[Macro  Att  ributeT  y  pe  \ 

[TypeAttributeTypel 
[DeseriptorAttributeType]  -> 

BEGIN 

NOT  A£eleted  -»  HasBinding  <-  TRUE; 

AJ3eleted  AND 

A.VersionNumber  GT  OldBasisVersionNumber  OR 
A.CreationNumber  GT  OldBasisVersionNumber  -> 
ChangedSnding  <-  TRUE; 

END; 

[ModuleLocalAttributeType]  -> 
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BEGIN 

IsChanged(A)  ->  ReDoAII  <-  TRUE; 

NOT  IsBasisModuie  AND  NOT  A.Deleted  -> 
Known  <-  FALSE; 

END; 

[ScopeLocalAttributeType]  -> 

BEGIN 

IsChanged(A)  ->  ReDoAII  <-  TRUE; 

NOT  A.Deleted  ■*>  Known  <-  FALSE; 

END; 

[AnalogiesAttributeType]  »> 

BEGIN 

IsChanged(A)  ->  ChangedAnalogy  <-  TRUE; 
A-Deleted  ->  NOTHING; 

AA  <-  A; 

END; 

END; 

END; 

Known  AND  HasBinding  -> 

BEGIN 

Add  ELName  ToSet  GJobals; 

ChangedBinding  ->  ReDoAII  <-  TRUE; 

END; 

Known  AND  AA  •  NullAttributa  ->  _ 

AddT o  Analogy  Set( Global  Analogies, 
AttributeValueOf(AA)); 

Known  AND  ChangedAnalogy  ->  ReDoAII  <-  TRUE; 
EM* 
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3-4  AddScopaLocalAnalogieo AndNamae  <- 
EXPR(E£ntity, 

ReOo$cope£OOL  SHARED, 

ScopaAnalogiaaiAnaiogySet) 

BEGM 

DECL  ScoptLocaigOOL  BYVAL  FALSE; 

OECL  HeaSndinfiBOCX.  BWAL  FALSE; 

PECL  AAdtttributat 

DECL  ChangadAnalogy  :BOOL  BYVAL  FALSE; 

DEa  TAAttribute; 

For  EachAttri  bote  A  of  E 
REPEAT 
CASE[A.Type] 
flBndlngAttributeTypel 
fLtecroAttributoT voe  1 
[DoecriptorAttrlbuteType]  NOT  A£oleted  ■> 

Hm Binding  <-  TRUE; 

[TypeAttributoType]  NOT  ADeloted  -> 

£)  HaeBhxMng  <-  TRUE;  TA  <-  A  (J 
[ScopeLocalAttributeType]  -> 

BEGIN 

laChanged(A)  ->  RaOoScopa  <-  TRUE; 

NOT  AJSalated  ->  ScopeLocal  <-  TRIE; 

END; 

[AnalogieaAttributeType]  -> 

BEGM 

lsChanged(A)  -»  ChangadAnalogy  <-  TRUE; 
AAeleted  ->  NOTHING; 

AA  <-  A; 

END; 

END; 

END; 

ScopeLocal  AND  HaaBInding  -> 

PuahLocalName<ELName, 

BEGM 

TA  -  NullAttributa  ->  ANY; 
AttributeValueOffTA); 

END); 

ScopeLocal  AND  AA  •  NullAttributa  -> 
AddToAnatogySetlScopaAnalogiaa, 
AttributeVatueOf(AA)); 

ScopaLocal  AND  ChangadAnalogy  ->  RaOoScopa  <-  TRUE; 


HHtmi  itiiimnHiH  hh  Attributaa  +*  »»»♦»»+♦ 
4-1  AttributeVaiueOf 


AttrlbutaVaiuaOf  laa  Procedural  AiAttribute;  FORM)  — 
Ratuma  the  value  of  the  attribute  A. 
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4-2  NullAttribute 

NullAttribute  isa  Attribute; 

4-3  AttributaType 

AttributaType  isa  MODE; 

4-4  BndingAttributaType 

Sncfln*AttributsT ype  isa  AttributaType; 

4-5  MscroAltributsType 

MecroAttributeType  isa  AttributaType; 

4-6  KnownPraesAttributeType 

KnownFraasAttributaTypa  isa  AttributaType; 

4-7  RewritesAttributeType 

RewritaaAttributaTypa  isa  AttributaType; 

4-8  TypeAttributeType 

TypaAttributaTypa  isa  AttributaType; 

4-9  Descriptor AttributaT y pa 

OaacriptorAttributaTypa  isa  AttributaType; 

4-10  AnatofiesAttributsType 

AnaiofiasAttributaTypa  isa  AttributaType; 

4-11  ModuleLocaiAttributeType 

ModuiaLocalAttributaTypa  isa  AttributaType; 

4-12  ScopotocalAttributsTypo 

ScopaLocaiAttributeTypa  isa  AttributaType; 
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♦  ¥** »+»++++ »♦+♦+♦ »+»+++++♦  InterfaceToPOS  mwwwww > m i«*m 
5-1  Scope 
Comment 

This  scope  contains  the  two  procedures  FllQ  and  FU  that  are  called  directly  through  the 
user  interface  and  that  have  the  responsibility  of  interpreting  the  call  arguments, 
determining  the  modules  involved,  and  so  on. 

Following  are  a  host  of  constructs  that  are  defined  within  the  PDS. 


EndComment; 


5-2  FUQ  <- 

EXPRtGsnerateProceduresCalledAttribute:BOOL, 
ReaultSpecsFORM  UNEVAL, 

BesisSpeciFORM  UNEVAL; 

Module) 

FUKGenerateProcedurasCalledAttributs,  RasultSpec, 
0  BasisSpec  e  ML  -»  SasiaSpec;  RasultSpec  Q)» 


5-3  FU  <- 

EXPRtGenerateProceduresCalledAttributedXXX, 
Result iModdeDescriptor  BYVAL, 
GfaModuieOaecriptor  BYVAL; 

Module) 

BEQN 

OECL  BasissModuia  BYVAL  CurrentModuletB* 
DECL  ConcreteCaaeflOOL; 
lsNullModule< Basis)  -> 

BEQN 

PRWTC 

There  is  no  module  for  descriptor  'X 
PWNTCB* 

NuilModuie; 

OGCL  UsesdFQRM  UKE 


BasiaAJsea  —  Null  -> 

BESM 

InataMEhtitloeAndAttributaeCBaaia,  ET,  A1> 
OomModuMBitJft)i 
ENOt 

BWlSaUfeMl 

EJQ 

OECL  IhrvePartttioroBOOL  BYVAL 
RssUtPartitlon  e  NuUPvtiboningt 
CONSTONT  UKE  ResULPartitlon)  -  1  -> 

ReauttPartitlon  *•  Null  Partitioning; 

OECL  MWfT  UKE  NeArfstUbee)  ♦  1; 

OECL  QldPsrentOaecrlptornggyMaduleDescrlptor)  SIZE 
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* 

OWPsrantDescriptor*  [1  ]  «- 
VacsionFraaDe*criptor(Bs«ts); 

NOT  HavePartitfon  -> 

RaaultPartition  *■  BasisPartition; 

OECL  JsWT  SYVAL  1; 

ForEachListElemant  m  in  Use* 

REPEAT 

OWParentDaecriptorstj  «-  j  +  1]  «* 

CONST(Modui«OMcriptor  LIKE  StripComraanKm)); 

ENft 

OECL  Parents£EQ(Moduie)  SIZE  Ni 
Parentsfl]  *■  Basis; 

OECL  AbortfiOOU 
FOR  j  FROM  2  TO  N 
REPEAT 
ParantsO]*- 
BEON 

ConcrataCasa  -> 

LocataOldConeratiaadModuMOIdParantOascriptorsO]); 
LoeataBasisForTooKOMParantDaseriptorsOl 
"Concretize  ”); 

END; 

NOT  HavaPartition  -> 

RasuitPartition  *- 
UMonPartltionatRaaulLPartition, 

ParantsDJPartitlon), 

lsNullModuia(Parents[j])  AND 
AutomaticallyGensratoWhenPosaible  -  TRUE  AND 
ConcrataCasa  -> 

BEGIN 

LoadPsckagsCCR^i 

Parents£j] «-  CRtOldPaFantDascriptorsOSl 
END; 

lsNuilModuie<Parsnts[j])  -> 

BEG3N 

PRINTC 

Thara  in  no  module  for  dsscriptor  T; 

PRWT(OWParentOeecriptors[j]>l 
Abort «-  TRUE; 

END; 

END; 

Abort  ■» 

BEGN 

PBNTC 

Abortint  FlndUndefinecRdentlfiers  T» 

Nul  [Module; 

END; 

OECL  FSMgyntsxMarfc  BYVAL  MarXSyntaxOi 

InstsilPDSSyntaxOi 

CdncratoCiM 


Install  Sped  siAttribute*(Basis)i 
Dasis  FsportadSyntax  a  NR.  *» 
Naw8yntsx<Basi«,ExportadSynta>)} 
Basis.LocalSyntsx  a  ML  -» 
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NcwSyntax<BMislocalSyntax)i 

ETO 

OECL  NawHMoryjModulaWatory  UKE 
Mak*H«tory<aFindUnci*fln*d)d*ntif<*r*ai  Paranta, 
BEGIN 

GaoarataProcadurasCaJladAttrlbuta  -> 

QUOTE{TW£)s 

QUOTE(FALSEX 

ENOk 

OECL  OMRaauttA4odula  UKE 
LocataFlndUnd#ttnadldantifiaraModula(Baaia)j 
DECL  Raault Moduia  UKE 
BEG9N 

NOT  IncanpatiblaHlitoriaaO^awHIstory, 

OMRaaultHstory)  -> 

DarivaModuMOkfflaault,  OMRaaultHMory)} 

NOT  GanarataProcaduraaCatladAttrlbuta  AND 
OWRaaUtHatory  Parameter*  •  QUO  TE(  TRUE)  AND 
BEQN 

OECL  HAtedulaHlatory  BYVAL  NawHIatoryj 
KParamatarc  <-  QUOTE{TRl£)i 
NOT  lneompattbiaHiitoriaa(K 

OMRaaulLHbtory)  -> 

TRUE- 

FALSE; 

END  «■» 

begin 

GanarataProeaduraaCalladAttributa  <-  TRIE; 
DarivaModuMOMRssult,  OUWaaiAHatory); 

END; 

RMulLDarivationNumbar  NullDarivattonCount; 
FOR  j  TON 
REPEAT 

Paranta{jlDarivat>onNunibar  GT 
RaaultDerivationNumber  -> 
RaaulLDarivationNumbar  *~ 
ParwitaOJDarivationNumbar; 

ENOt 

RasuItJDarivationNumbar  ♦* 
RaauitDarivatlonNumbar  ♦  1; 
RaaulLFanOutNumbar  v 
FlndUndafln^ldantlflaraFaiKXjtNumbarj 
DarivaModuMRaault,  NawHwtory,  TRUE); 

END 

RaataraSyntax(FSM)i 

Raault; 

END; 
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5-5  Attribute 

Attribute  isa  MODE; 

5-6  Module 

Module  ioa  MOOE; 

5-7  ModuieOeecriptor 

ModuleOescriptor  iaa  MOOE; 

5-8  CurrentModule 

CurrentModule  iaa  ProcedureWsModuleQeseriptor;  Module)  — 

Return*  the  current  (Le.  the  lateat  veraion)  of  the  module  with  deacriptor 

5-9  IsNull  Module 

laNuUModuie  iaa  Proeedure(m:Module;  BOOL)  — 

Returns  TRUE  iff  m  is  a  null  module. 

5-10  NullModule 

NullModule  isa  Module; 

5-11  Null 

Null  isa  SYMBOL; 

5-12  Partition 

Partition  iaa  MOOE; 

5-13  NuflPartitionin* 

NullPartitionin*  ise  Partition; 

5-14  UnionPsrtfflons 
UnionPartltlona  Iaa 

Procedure(plrf>artition,  p2d*artUtonj  Partition)  - 
Tahoe  the  union  of  pi  and  p2- 


Module  <FUI  9  54>  Scope<Interf  aceT  oPDS) 


C- 17 


5-15  OerivationCount 

DerivettonCount  isa  MODE; 

5-15  NullOerivationCount 

NullDerivationCount  iaa  DerivationCount; 

5-17  FanOutCount 

FanOutCount  iaa  MOOE; 

5-18  FindUndefinadldentifiersFanOutNumber 

FindUndefinedldentifiersFanOutNumber  iaa  FanOutCount; 

5-19  Syntax  Mark 

Syntax  Mark  iaa  MOOE; 

5-20  MarkSyntax 

MarkSyntax  isa  Procedure^  Syntax  Mark)  — 

Rat  urns  a  mark  ra  tha  currant  topmost  syntax  definition  sntarad  by  NewSyntax. 

5-21  RastoraSyntax 

RastoraSyntax  isa  Procadura<tm5yntaxMark}  — 

Removes  ail  syntax  sntarad  by  calls  on  NewSyntax  sines  that  corresponding  to  tys  mark, 

m. 

5-22  NewSyntax 

NewSyntax  isa  Procadura(sdrORM)  — 

Adda  tha  fixity  definitions  contained  in  tha  list  a  to  tha  syntax  currently  in  place. 

5-23  VersionFroeDsscrlptor 
VsrsionFrssDsscrlptor  iaa 

ProcaduratddvIodulaDaacriptor;  ModulaOaacriptor)  — 

Returns  a  module  descriptor  for  version  "0*  of  the  module  corresponding  to  tha  descriptor 
d. 
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5-24  DetectChanges 
Analogies 

SetupToDetectChangesSineedl  x)  <}>  It  x; 
OdBssisVerslonNumber  <}>  Oj 
IsChangeddt  •)  <}»  If  a, 

EndAn  stogies; 


5-25  CloseModule 

Cloaa Modulo  isa  Procadure<LeModuls)  — 
Close  tha  module  M. 


5-26  InstallNewModule 

InstallNewModule  isa  Procedure<MModule)  — 

Install  tha  modula  M  in  tha  currant  system. 


5-27  StripComment 

StripCommant  isa  Rrocedure(f:FORMl  FORM)  — 

Remove  the  comment  component  of  f,  if  any. 


5-28  LocateOldConcretizedModule 

Located dConcretizedModule  isa 
Procedure(d:ModuleDescripton  Module)  — 

Return  the  concrete  module  corresponding  to  the  descriptor  d. 


5-29  LocateSasisForTool 
LocateBasisFor Tool  isa 

Procedure(cbModuieOosciiptor,  t^YMBOU  Module)  — 

Return  the  module  correspond^  to  that  named  by  d  derived  by  the  tool  named  L 


5-30  LocateRndUndefinedldentifiersModule 

LoeateFindUhdeftnedldentifiersModule  Isa 
ProcedurefehModuleOescrlpton  Module)  — 

Return  the  module  correspond  ng  to  d  that  was  derived  by  FUL  . 
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5-31  AutomaticallyGenerateWhenPossible 

Automatic  sIlyGenerataWhenPossible  its  BOOL; 


5-32  LoadPackage 

LoadPackage  isa  Procedure(p:$YMBOL)  — 
Load  tho  package  namad  p. 


5-33  CR 

CR  isa  ProcedureOmModulej  Module)  — 

Derive  and  ratum  tha  concrata  modula  corresponding  to  modua  m. 


5-34  hstallPOSSyntax 

InstailPOSSyntax  iaa  ProcedureO  — 

Ina tall  tha  syntax  aasumad  ganarally  applicable  when  using  the  PCS. 


5-35  InstallSpecialAttributes  ^ 

InstallSpacialAttributes  iaa  Proeedure<m:Module)  — 

Road  in  tha  Uses,  ExportedSyntax,  and  such  like  attributes  for  module  m. 


5-36  ModuleHstory 

ModuleHstory  isa  MOOEi 


5-37  Make  History 

Make  Hi  story  isa 
ProcadureCroohSYMBOL, 

Parents:SEQ(ModuJe), 

psBOOL; 

ModuleHstory)  — 

Construct  tho  ModuleHstory  par  using  Tool  to  derive  a  modula  from  Parents  with 
parameter  p. 


5-38  (ncompatibleHstories 
Incomp atibieHstori  as  isa 

Procedure(hl2:ModuloHstory,  h2sModuleH«toryt  BOOL)  — 
Returns  FALSE  iff  tho  histories  hi  and  h2  are  compatible. 
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5-39  DeriveModule 

DeriveModule  isa  Procedure<oJd:Module,  hrModuieflstory)  — 

Oariva  the  module  with  history  h  previously  derived  as  old)  that  la,  incrementally  rederive 
old. 


InterfaceToRewritePackage 

6-1  AnalocySet 

Analogy  Set  isa  MODE; 


6-2  Analogy  Environment 

Analogy  Environment  isa  MODE; 


6-3  PushAnatogies 

PushAnelogies  isa  Procedure(S:AnalogySet)  — 

Adds  S  to  the  current  analogy  environment 


6-4  PopAnaiogies 

PopAnalogies  isa  ProcedureO  — 

Removes  the  most  recent  AnalogySet  pushed  into  the  current  analogy  environment  from 
that  environment 


6-5  AddToAnalogySat 
AddToAnaiogySet  isa 

Procedura<AEnviAnalotyEnvironment,  af ORM)  — 
Add  the  analogy,  a,  to  the  environment  AEnv. 
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7-1  Macallanaoua 

Anatogiaa 
ErrorO  <}>  MU 

Setdt  m)  <}>  St  mt 

LoadAppropriataPackagaaO  <}>  MU 

AnnouncaTooKtt  t,  II  m)  <}>  II  mj 

NawFraaVariablaaAttributaFordl  E,  »  A,  II  L>  <}> 

WE  +  WA  +  ISU 

NawProcaduraaCaUedAttritHJteFor<!l  E,  M  A,  II  L)  <}> 

IIE  +  IIA  +  IIU 

SaveProndurMCaltedAttributoFordl  m)  <}>  «  m; 
InitiaiizsRaaultModuiedl  m)  <J»  H  mj 
Initializa  Par  Scopa<  II  a)  <}»  It  *{ 

InataHKnownFr— a(H  kf)  <}>  n  kfj 
RamavaKnownFraaaO  <}>  MU 
RamovaScopaOapandafltAnaiOfiarAndNamaaO  <}>  MU 
InataUEntitiMAndAttributaadl  m,  ET,  AT)  <}>  n  m; 
FatchEntitiaaAndAttributaaFordl  m)  <}>  II  mj 
EndAratogfeat 


Table  Of  Contents 


FUlH  2-3  .  abfwln  of  IntorfoeoToAnolyco 

3- 4  .  AddSenpoLneulAnolBpinfoittnni  of  FlndUndofino Sdontifioro 

6- 5  AddTeAnolofySot  of  Intnrf wT oft— f itePthf « 

4- 10  Anolotinn  AttrinitnTypo  of  Attrfertoo 

r*k  WQfyLWTWWIm  hi 

0-1  AnnlofySot  of  IntorfocnToflowitnPorlinto 

2-1  •  Me  of  IntorfocoToAnotyoo 

£4  •  AnotyioCr rorT otJoor  of  lolorfocoToAnatyto 

2-2  •  AnolyoHoxpUnfcnotenAtoni  of  IntorfoeoToAnolyo 

2-4  •  AnotyonProconoBofcnwIorfunetiono  of  IntorfoeoToAnolyzo 

2-3  •  AnolyeoProcooolJoorPrnroitiroAfiplirotinn  of  IntorfneoTaAnoiyBO 

5- 5  Attrfeuto  of  IntorfoeoToPOS 
4-3  AttrfeutoType  of  Attrfcutoo 

4- 1  AttrtetoVeluoOf  of  Attrfeutoe 

5- 31  AueooatieoiyGenorotellMonPoeelilo  of  InterfneeToPDS 

4- 4  BodtapAttributoTypo  of  Attrbutno 

5- 25  CbooModulu  of  IntorfoeoToPOS 

M3  at  at  InterfoeeToPOS 

5-3  CurrontModulo  of  IntorfoeoToPOS 
5-15  DorivetionCount  of  IntorfoeoToPOS 
5-39  DorivoModute  of  IntorfoeeToPOS 

4- 9  OoocriptorAttrfcuwTypo  of  Attributoo 

5- 24  OotoctOnnt—  of  IntorfoeeTaPOS 

2-10  •  DoAnolyoinOf  of  IntorfneoToAmiyin 
5-4  Entity  of  IntorfoeoToPOS 

5-17  FanOutCouot  of  IntorfoeeToPOS 

5-13  n  dUndofl  nertontifiofoT dnOuStnubnt  of -IntorfoeoToPOS 

5-3  -  FU  of  IntorfoeoToPOS 

5-2  •  FUQ  of  IntorfoeoToPOS 

5-33  IncnuyotMoliotonno  of  IntorfoeoToPOS 

5-26  InetnMooHdoduie  of  fatorfteeToPOS 

5-34  InntMPOSSyntnn  of  kitorfneoToPOS 

5-35  iMirfSpiciriAttfhrtii  of  IntorfoeoToPOS 

5-9  loMMModjIo  of  IntorfoeoToPOS 

4- 3  Kneo>nFronnAttrfci»toTy|>o  of  Attihutoo 

5- 32  InodPoefcofo  of  IntorfoeoToPOS 
5-29  LoeotoBooioForTool  of  IntorfoeoToPOS 

5-30  UcotoFindUndofinndMnntifloi’oliInriulo  of  IntorfoeoToPOS 
5-23  locotoOtdConerotloodModulo  of  IntorfoeoToPOS 

4- 5  Moti'oAttrhutoT ypo  of  Attrfeutoo 

*•/  •  MnrfiivirMMciRFyraf  or  Kuarrica  i<ywvya 

5- 37  MMoKotnry  of  IntorfoeoToPOS 
5-20  lhW)nln  of  IntorfoeoToPOS 

7- 1  Xooofcnoouo  of  llh  sitiiiim  i 

5-3  Modulo  of  IntorfoeoToPOS 

1  Modulo 

5-7  MoiluloOooulptur  of  IntorfoeoToPOS 
5-39  Moduioliulary  of  lotorfoooToPOS 

4- 11  MoMdoioaolAttHhutoTypo  of  Attrftwtoo 

5- 22  NouMyntK  of  IntorfoeoToPOS 

2- 9  •  MotMAdetoo oBoAnuiorFunetlon  of  IntorfoeoTaAnolyeo 
5-11  MM  of  lotorfoooToPOS 

4- 2  MdMttrftwte  of  AttrMutoo 

5- 16  MdPorirotinnCniiot  of  IntorfoeoToPOS 
5-10  MMModulo  of  IntorfoeoToPOS 

5-13  MMPortMoninf  of  IntorfoeoToPOS 
FU  •  54  5-12  Poitltloo  of  lotorfoooToPOS 

3- 4  PapAnolocloe  of  IntorfoooToBowrHoPoelto 
9-3  MtoAPoMocioo  of  IniorfoaeToAoiorttoP^Bto 
Ml  AootoroHyotn  of  IntorfoeoToPOS 

4- 7  nooiHooAtti  MitoTypo  of  Attrfcwtoo 

5- 1  Soopo  of  tatorfoetTePOS 

9-1  Soopo  of  FMUndoflnodMootinoro 

4- 12  SoopetocolAttrtbutoTypo  of  Attrfcutoo 

5- 27  ftripCfottnl  of  IntorfoeoToPOS 
9>19  IfiilouMoiti  of  InlorfoeoToPOS 


Table  Of  Contents 


C  -  23 


4- 4 

5- 14 
2-S 
5-23 


TypWtttrfaittTypo  of  Attttartoo 
UniooP*tMo«o  of 

VoSdBotawiorFunetioo  of  kiioi  focoTuAoofyoo 
VoroionFrooOooeriptor  of  IfitorfocoToPOS 


DATE 

FILMED 


